MAXPAR/NUMPAR upper limit

Topics about the HYSPLIT dispersion model.
Post Reply
neeldip
Posts: 7
Joined: February 8th, 2018, 1:01 pm
Registered HYSPLIT User: No

MAXPAR/NUMPAR upper limit

Post by neeldip » March 13th, 2018, 11:46 am

I am trying to run a particle dispersion. Particle released per cycle ~ 1.97E+21. I have only one source. However when I set this number in NUMPAR and then the MAXPAR accordingly, the model just stops with an error sound with no further calculation.
Model started ...
HYSPLIT4 - Initialization
Last Changed Rev: 927
Last Changed Date: 2018-01-25 16:56:26 -0500 (Thu, 25 Jan 2018)


1) What is the upper limit on NUMPAR/MAXPAR?
2) How should I proceed with this particle dispersion simulation?

System specs:
Core i5 3570k, 16 GB RAM, Win 10 pro, NVIDIA GPU.

ariel.stein
Posts: 622
Joined: November 7th, 2012, 3:14 pm
Registered HYSPLIT User: Yes
Contact:

Re: MAXPAR/NUMPAR upper limit

Post by ariel.stein » March 13th, 2018, 4:22 pm

1.0E+21 particles is way too much for any computer to handle. We have tested the model with a few million particles but never with so many. Please try with fewer particles.

neeldip
Posts: 7
Joined: February 8th, 2018, 1:01 pm
Registered HYSPLIT User: No

Re: MAXPAR/NUMPAR upper limit

Post by neeldip » March 14th, 2018, 8:43 am

Thank you for the clarification.

I have release rate of ~60000 g/hr from a city area.
I calculated the particle number as: x*density*volume of 1 particle = release rate = 60000 , where x denotes the no. of particles.

a)So is the NUMPAR an assumed number and not the actual no. of particles being released?
b)If I take fewer particles, won't the particles have a higher mass and be more prone to deposition?

ariel.stein
Posts: 622
Joined: November 7th, 2012, 3:14 pm
Registered HYSPLIT User: Yes
Contact:

Re: MAXPAR/NUMPAR upper limit

Post by ariel.stein » March 15th, 2018, 10:11 am

The lagrangian particles you are releasing in the model do not represent molecules. The intend of the model is to depict the transport, dispersion and deposition of coherent eddies represented by a distribution of lagrangian particles.

neeldip
Posts: 7
Joined: February 8th, 2018, 1:01 pm
Registered HYSPLIT User: No

Re: MAXPAR/NUMPAR upper limit

Post by neeldip » March 19th, 2018, 12:08 pm

I have some confusion in the deposition.
So when we set the pollutant as a particle by assigning the diameter, density, etc; then aren't these properties assigned to the particles we are releasing? i.e the particles defined in the CONTROL file are different from the particles being released?
In that case how is the settling velocity calculated using Stokes law.

If I have 10g/particles being released and my actual pollutant particle size is around 1 um with density of 1.5 g/cc, then the mass of the particle doesn't match up.
If possible kindly provide some links. It'll be of great help.
Thank You.

MarkCohen
Posts: 12
Joined: August 5th, 2016, 11:56 am
Registered HYSPLIT User: Yes

Re: MAXPAR/NUMPAR upper limit

Post by MarkCohen » April 2nd, 2018, 1:08 pm

Hi, sorry it has taken awhile to respond to your last question.

In looking at your questions in this thread, I think the key issue is a what a HYSPLIT "particle" really represents.

The "particles" being released and tracked in a HYSPLIT simulation (using the default dispersion mode: 3-D particle) should be thought of as "computational particles" (or computational points) and not as actual atmospheric aerosol particles.

Without any deposition or settling considered, these computational particles are simply transported and dispersed by the model. The model automatically divides up the specified emissions among the number of computational particles that you specify, so that the total emissions are equal to the sum of the mass on all of the computational particles. If you specify fewer computational particles, then there will be more mass per computational particle, but the total mass emitted will still be what you specify. It is important to understand that the computational particles are being used to simulate a continuous plume, and that each computational particle represents a portion of the plume.

All things being equal, the concentrations calculated by the model will be equivalent no matter how many computational particles you use, subject to the limitation that with fewer computational particles in the concentration grid, you will tend to see a more "blotchy" plume. That is, there may not be enough computational particles to give you a good distribution, so you will see one grid square that happens to have one of the few computational particles (with a lot of mass on it), and the concentration is calculated by the model to be very high in that grid square, but then the adjacent grid square does not have one of the few computational particles, and so the model calculates the concentration to be "0" in that grid square. In reality, and if you used more computational particles in the calculation, you would likely get a more continuous distribution of concentrations. This all depends of course on the horizontal and vertical resolution of the concentration grids that you define. All things being equal, if you define a finer concentration grid, you will need more computational particles to create a more realistic plume distribution than with a coarser grid. There is no one right answer. My recommendation is generally to start with one specified number of particles, and then see if the answer changes if you change the number of computational particles. You want to find the "sweet spot" for your situation where you have enough computational particles to get a satisfactorily realistic simulation, but where the answer doesn't really change if you add more computational particles. If the answers keep changing as you add more particles, this generally means that you are not at the "sweet spot" yet, and you probably need to add more computational particles. When you are experimenting with this, think of 100's or 1000's or computational particles, perhaps eventually getting up to tens of thousands or maybe higher. In my own work, I've never had to go as high as a million particles to get a good simulation.

Now, when you turn on dry and/or wet deposition and/or gravitational settling by specifying appropriate values in the CONTROL file (e.g., through the Graphical User Interface), then you are simply telling HYSPLIT how it should handle these computational particles with regard to deposition. If, for example, you define your pollutant to be an aerosol particle with a certain size and density, then you are telling HYSPLIT to treat the computational particles as if they had these characteristics, but only for the purposes of estimating the amount of the pollutant that is deposited. Each computational particle will actually represent a LOT of the actual aerosol particles. In the case of a gaseous pollutant, the same idea applies, and each computational particle will represent a LOT of actual gaseous molecules. As discussed above, you will get the same answer for concentrations and deposition for the same emissions rate no matter how many computational particles you use, as long as you have "enough" computational particles to create a relatively continuous distribution within your user-specified concentration grid(s). If you have fewer computational particles, each one will represent a larger number of your actual aerosol particles or gaseous molecules. When you add computational particles, each one represents proportionally less actual aerosol particles or gaseous molecules (but still generally a LOT of them). In general, you will always have many, many orders of magnitude less computational particles in your simulation than the actual aerosol particles or gaseous molecules that you are trying to simulate.

I hope this discussion has helped. It is perhaps unfortunate that we have used the term "particle" to represent the computational elements with the 3-D particle-mode computational scheme in the HYSPLIT model. You are by no means the first person who has run up against this when trying to get their head around what the model is really doing!

neeldip
Posts: 7
Joined: February 8th, 2018, 1:01 pm
Registered HYSPLIT User: No

Re: MAXPAR/NUMPAR upper limit

Post by neeldip » April 8th, 2018, 10:05 pm

It indeed an insightful reading. Thank you for the explaining it descriptively. It cleared up my doubts.

wsr
Posts: 8
Joined: August 23rd, 2017, 12:08 am
Registered HYSPLIT User: No

Re: MAXPAR/NUMPAR upper limit

Post by wsr » August 25th, 2018, 8:13 pm

I am not sure this question was answered. This would be helpful for those like me who find it later and actually need a definitive answer on the largest MAXPAR/NUMPAR that can be used. In particular, I soon will need to set up a run of ~1E9 particles at any given model time step. With the variety of modes and functions that can be activated in the dispersion model, the "We have tested up to X many" punt is not very helpful. I cannot break this down into several runs because it is not possible to adjust the random seed.

Post Reply