You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, this helps. Now, for nesting, would you expect it to work as if a <suite ...> entry in a suite works like an include statement? That is, it would be as if you cut and pasted the contents of the suite into that location. If not, please explain how you think this should work.
One important requirement is that the proposed <suite ...> entry must include both a suite name and a group name so that the schemes from the correct run-time group can be 'copied' into place. However, it is less clear on how to handle initialization. Do we have to initialize the entire nested suite? If so, where does it go in the initialization sequence? If not, how do we know when initialization (and finalization) routines to run and when to run them?
All of this needs to be discussed in the GitHub issue.
--Steve
On Fri, Aug 16, 2019 at 12:14 PM Andrew Conley aconley@ucar.edu wrote:
Hi Steve,
It is not a loop over species, but a loop over reactions. Every reaction has a rate constant associated with that rate constant. Each rate constant depends upon a heterogenous set of environmental factors (temperature, pressure, surface area density, mean radius of the cloud droplet, or some other random thing). The units of the returned rate constant is also distinct between each rate constant computation.
So each rate constant seems to be ideally qualified to be its own scheme.
The nesting is not terribly relevant, but the idea of separate schemes seems appropriate to the CPF framework standards.
Does that help?
-- Andrew
The text was updated successfully, but these errors were encountered:
We would like to have the ability to have a suite listed within a suite. This would be a convenient way to group related schemes together into a single entity. In the case of chemistry, this can hide the hundreds of entries required and allow the scheme list to be more easily reviewed.
It should be treated as an "include" and would operate as if the entire contents of the suite were listed in place of the suite. Initialization, run and finalize would occur for each scheme as if they were individually listed. It can be thought of as adding a subroutine around a list of other calls in fortran.
@gold2718 @AndrewJConley
From the email chain prior to opening this issue:
Yes, this helps. Now, for nesting, would you expect it to work as if a <suite ...> entry in a suite works like an include statement? That is, it would be as if you cut and pasted the contents of the suite into that location. If not, please explain how you think this should work.
One important requirement is that the proposed <suite ...> entry must include both a suite name and a group name so that the schemes from the correct run-time group can be 'copied' into place. However, it is less clear on how to handle initialization. Do we have to initialize the entire nested suite? If so, where does it go in the initialization sequence? If not, how do we know when initialization (and finalization) routines to run and when to run them?
All of this needs to be discussed in the GitHub issue.
--Steve
On Fri, Aug 16, 2019 at 12:14 PM Andrew Conley aconley@ucar.edu wrote:
Hi Steve,
It is not a loop over species, but a loop over reactions. Every reaction has a rate constant associated with that rate constant. Each rate constant depends upon a heterogenous set of environmental factors (temperature, pressure, surface area density, mean radius of the cloud droplet, or some other random thing). The units of the returned rate constant is also distinct between each rate constant computation.
So each rate constant seems to be ideally qualified to be its own scheme.
The nesting is not terribly relevant, but the idea of separate schemes seems appropriate to the CPF framework standards.
Does that help?
-- Andrew
The text was updated successfully, but these errors were encountered: