@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
@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