Many of these models have been around for a long time, I gather, so the parallelism must have been added fairly recently. So why MPI rather than co-arrays?
On Monday, March 15, 2021 at 12:41:10 PM UTC-4, Clive Page wrote:steps) that do not translate cleanly into co-array form.
[snip...]
Many of these models have been around for a long time, I gather, so the parallelism must have been added fairly recently. So why MPI rather than co-arrays?For meteorology models, the parallelism was added in the late 1980's and early 1990's.
Moreover, the thermodynamics/cloud/convection/chemistry related computations (which are most of the calculation, fwiw) are quite intricate calculations at each individual grid cell or each individual vertical grid-column (frequently with internal time
FWIW
On Monday, March 15, 2021 at 12:41:10 PM UTC-4, Clive Page wrote:steps) that do not translate cleanly into co-array form.
[snip...]
Many of these models have been around for a long time, I gather, so the parallelism must have been added fairly recently. So why MPI rather than co-arrays?
For meteorology models, the parallelism was added in the late 1980's and early 1990's.
Moreover, the thermodynamics/cloud/convection/chemistry related computations (which are most of the calculation, fwiw) are quite intricate calculations at each individual grid cell or each individual vertical grid-column (frequently with internal time
FWIW
On 2/15/2022 11:31 AM, cjcoats wrote:steps) that do not translate cleanly into co-array form.
On Monday, March 15, 2021 at 12:41:10 PM UTC-4, Clive Page wrote:
[snip...]
Many of these models have been around for a long time, I gather, so the parallelism must have been added fairly recently. So why MPI rather than co-arrays?
For meteorology models, the parallelism was added in the late 1980's and early 1990's.
Moreover, the thermodynamics/cloud/convection/chemistry related computations (which are most of the calculation, fwiw) are quite intricate calculations at each individual grid cell or each individual vertical grid-column (frequently with internal time
FWIW
We have the same problem in our chemical process simulator. The
saturation calculations rule everything in the four phases (vapor,
liquid hydrocarbon, aqueous liquid, solid) and are not very parallelizable.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:time steps) that do not translate cleanly into co-array form.
On 2/15/2022 11:31 AM, cjcoats wrote:
On Monday, March 15, 2021 at 12:41:10 PM UTC-4, Clive Page wrote:
[snip...]
Many of these models have been around for a long time, I gather, so the parallelism must have been added fairly recently. So why MPI rather than co-arrays?
For meteorology models, the parallelism was added in the late 1980's and early 1990's.
Moreover, the thermodynamics/cloud/convection/chemistry related computations (which are most of the calculation, fwiw) are quite intricate calculations at each individual grid cell or each individual vertical grid-column (frequently with internal
FWIW
We have the same problem in our chemical process simulator. The
saturation calculations rule everything in the four phases (vapor,
liquid hydrocarbon, aqueous liquid, solid) and are not very parallelizable.
I can well imagine, especially if you are doing iterative calculations
of your equilibria.
(Side remark: I do hope your program converges better than Aspen Plus
does. If you use a converged solution as a starting value there, that program will likely diverge. I have no polite words for that kind
of numerics).
On 2/16/2022 3:15 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We have the same problem in our chemical process simulator. TheI can well imagine, especially if you are doing iterative calculations
saturation calculations rule everything in the four phases (vapor,
liquid hydrocarbon, aqueous liquid, solid) and are not very parallelizable. >>
of your equilibria.
(Side remark: I do hope your program converges better than Aspen Plus
does. If you use a converged solution as a starting value there, that
program will likely diverge. I have no polite words for that kind
of numerics).
The problems happen when a solution ends up in multiple phases and one
of the components is a strong polar like water and / or an alcohol. We
fight with that all the time.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 2/16/2022 3:15 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We have the same problem in our chemical process simulator. The
saturation calculations rule everything in the four phases (vapor,
liquid hydrocarbon, aqueous liquid, solid) and are not very parallelizable.
I can well imagine, especially if you are doing iterative calculations
of your equilibria.
(Side remark: I do hope your program converges better than Aspen Plus
does. If you use a converged solution as a starting value there, that
program will likely diverge. I have no polite words for that kind
of numerics).
The problems happen when a solution ends up in multiple phases and one
of the components is a strong polar like water and / or an alcohol. We
fight with that all the time.
With Aspen, it is more like every time you have a recycle stream :-(
I am glad I no longer work with that program (and I only used it
a few times).
However, it is still not clear what goes wrong. Surely, if your
flash calculation has converged so that energy and mass balances
and equilibria are satisfied, you should be able to test for that?
Or is it a problem with derivatives that you try to calculate where
one point is inside the flash regime and the other one outside?
On 2/16/2022 2:47 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 2/16/2022 3:15 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We have the same problem in our chemical process simulator. The
saturation calculations rule everything in the four phases (vapor,
liquid hydrocarbon, aqueous liquid, solid) and are not very parallelizable.
I can well imagine, especially if you are doing iterative calculations >>>> of your equilibria.
(Side remark: I do hope your program converges better than Aspen Plus
does. If you use a converged solution as a starting value there, that >>>> program will likely diverge. I have no polite words for that kind
of numerics).
The problems happen when a solution ends up in multiple phases and one
of the components is a strong polar like water and / or an alcohol. We
fight with that all the time.
With Aspen, it is more like every time you have a recycle stream :-(
I am glad I no longer work with that program (and I only used it
a few times).
However, it is still not clear what goes wrong. Surely, if your
flash calculation has converged so that energy and mass balances
and equilibria are satisfied, you should be able to test for that?
Or is it a problem with derivatives that you try to calculate where
one point is inside the flash regime and the other one outside?
Yes, the worst is when one of the phases is on the knife edge of phase change, usually water. More water than normal is in the vapor phase and
the rest of the water is in the aqueous liquid phase. Getting that to converge is a trick and can cause recycles to spin out of their
convergence zone as the solution flip flops between the phases. We have tried to modify our software so that bad initialization is ok but there
are always edge cases where the solution is backed into a corner.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 2/16/2022 2:47 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 2/16/2022 3:15 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We have the same problem in our chemical process simulator. The
saturation calculations rule everything in the four phases (vapor, >>>>>> liquid hydrocarbon, aqueous liquid, solid) and are not very parallelizable.
I can well imagine, especially if you are doing iterative calculations >>>>> of your equilibria.
(Side remark: I do hope your program converges better than Aspen Plus >>>>> does. If you use a converged solution as a starting value there, that >>>>> program will likely diverge. I have no polite words for that kind
of numerics).
The problems happen when a solution ends up in multiple phases and one >>>> of the components is a strong polar like water and / or an alcohol. We >>>> fight with that all the time.
With Aspen, it is more like every time you have a recycle stream :-(
I am glad I no longer work with that program (and I only used it
a few times).
However, it is still not clear what goes wrong. Surely, if your
flash calculation has converged so that energy and mass balances
and equilibria are satisfied, you should be able to test for that?
Or is it a problem with derivatives that you try to calculate where
one point is inside the flash regime and the other one outside?
Yes, the worst is when one of the phases is on the knife edge of phase
change, usually water. More water than normal is in the vapor phase and
the rest of the water is in the aqueous liquid phase. Getting that to
converge is a trick and can cause recycles to spin out of their
convergence zone as the solution flip flops between the phases. We have
tried to modify our software so that bad initialization is ok but there
are always edge cases where the solution is backed into a corner.
[Aspen is _far_ worse than what you describe]
I can imagine that this could be the case, especially if you have
termination errors of an iterative solver for the phase distribution.
One suggestion (from afar, and you may have tried this already):
If the calculations are right on the boundary of phase change,
you could calculate the liquid phase only, the equations will work
fine if you simply assume no gas phase. After that is converged, you
could then check if your total vapor pressure is larger than the
pressure in the process unit you are looking at, and then, if that
is the case, calculate the vapor phase under the assumption that
there is one. For a suitably small amount of vapor, you can also
assume that the concentrations in your liquid phase do not change,
so the vapor composition is fixed.
If you want to take this a little further, you might also be able
to do a calculation for a small amount of vapor, assuming a linear
change in concentration and temperature in your liquid phase with
vapor fraction or pressure or... This could be somewhat easier if
your thermodynamic quantities have explicit derivatives, which
I obviously don't know.
Nope, we use an iterative interpolation method for the adiabatic and isentropic flashes. For the isothermal flash we try to solve the knife
edge before falling into the interpolation method. For the constant
volume flashes we use the interpolation method after the modified
Wegstein fails (I call it the brute force method).
We have hundreds of solvers in our software. We are Frankenstein's
monster, built of many pieces. Our three main recycle solvers are all
flow based. I am going to add a pressure based recycle solver to that
group in the next year or two.
BTW, we have 60 different equations of state in our software. The
details of each EOS is hidden from the recycle and flash solvers,
otherwise they would be trying to do too much.
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
Nope, we use an iterative interpolation method for the adiabatic and
isentropic flashes. For the isothermal flash we try to solve the knife
edge before falling into the interpolation method. For the constant
volume flashes we use the interpolation method after the modified
Wegstein fails (I call it the brute force method).
This is getting a bit away from Fortran, but...
To me, a "flash" is something adiabatic: You reduce the pressure
from above the vapor pressure to below the vapor pressure of your
volatile components. Part of the volatile components evaporate,
leading to the formation of a gas phase and a drop in temperature due
to the enthalpy of evaporation (which some folks call "heat" due
to sloppy terminology).
Now, I can see what an isothermal flash would be, you add enough heat
to keep the temperature constant. I wouldn't call it that, but OK.
As for a "constant volume" flash - I'm not sure what process that I
would still consider a flash can be isochoric, every flash I know
expands in volume. But I guess that's all a matter of terminology.
We have hundreds of solvers in our software. We are Frankenstein's
monster, built of many pieces. Our three main recycle solvers are all
flow based. I am going to add a pressure based recycle solver to that
group in the next year or two.
Sounds like a challenge.
BTW, we have 60 different equations of state in our software. The
details of each EOS is hidden from the recycle and flash solvers,
otherwise they would be trying to do too much.
To bring this slightly back to Fortran: I think equations of
state could profit from Fortran's object-oriented features.
I would envisage an abstract type representing a substance, with
type-bound procedures for calculating the state depending on
whatever variables you want (let's say from p and T, or p and h,
or h and s, or ...) and which would let the user inquire about
the properties via other type-bound procedures.
If I were to implement something like that, this is probably the
approach I look at first. (The likelyhood of that happening is
10^-x, it is a few decades since I last played around implementing
an equation of state, it was when I was still at University).
We have two constant volume flashes:
1. constant volume and constant enthalpy (T and P float)
2. constant volume and constant temperature (H and P float)
Constant volume flashes are used for pressure vessels with internal
reactions or external heat energy (endothermic or exothermic).
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We have two constant volume flashes:
1. constant volume and constant enthalpy (T and P float)
2. constant volume and constant temperature (H and P float)
Constant volume flashes are used for pressure vessels with internal
reactions or external heat energy (endothermic or exothermic).
So, you use "flash" in a different sense than I do. Faiir enough,
computer science is not the only field beset by terminology
differences :-)
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
We have two constant volume flashes:
1. constant volume and constant enthalpy (T and P float)
2. constant volume and constant temperature (H and P float)
Constant volume flashes are used for pressure vessels with internal
reactions or external heat energy (endothermic or exothermic).
So, you use "flash" in a different sense than I do. Faiir enough,
computer science is not the only field beset by terminology
differences :-)
Hi,
An interesting article I ran across about Fortran and Climate Models
https://partee.io/2021/02/21/climate-model-response/
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 159 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 99:58:43 |
| Calls: | 3,209 |
| Files: | 10,563 |
| Messages: | 3,009,979 |