Derived parameters

[simonbyrne]

Currently we many parameters which are defined in terms of others, e.g.

• https://github.com/CliMA/CLIMAParameters.jl/blob/6f660320358bd2be611f382897aacf3084c66bf1/src/Atmos/atmos_parameters.jl#L82-L84
• https://github.com/CliMA/CLIMAParameters.jl/blob/6f660320358bd2be611f382897aacf3084c66bf1/src/Atmos/atmos_parameters.jl#L11-L13
• https://github.com/CliMA/CLIMAParameters.jl/blob/6f660320358bd2be611f382897aacf3084c66bf1/src/Atmos/atmos_parameters.jl#L71

The current TOML format under discussion (#58), this approach will no longer work. There are a couple of options that I can think of:

1. remove all derived parameters: instead they would need to be defined in user code
2. make them ordinary parameters (i.e. defined their values in the TOML file): the key risk here is that they could get out of sync if an ancestor parameter is modified
3. keep them as special (non-overrideable) parameters: this would depend precisely on how represent CLIMAParameters internally (Internal representation #59), but we could either have them defined in ordinary Julia code (rather than the TOML), or have some sort of special field in the TOML file that allows specifying expressions, e.g.:

[m0_ice]
depends_on = ["ρ_cloud_ice", "r0_ice", "me_ice"]
expression = "4/3 * π * ρ_cloud_ice *  r0_ice^ me_ice"

cc: @odunbar @trontrytel

[odunbar]

Thanks Simon,

One additional note: we are talking about parameter defaults being defined in terms of other parameter defaults here right?

[tapios]

We discussed this. There are two classes:

• Parameters that are derived from given parameters, with a functional form that is universally fixed in the model; we should make those functions in model code; e.g., Microphysics.m0_ice above.
• Parameters that are derived from other parameters, with a functional form that is usually (e.g., for Earth) but not always fixed; e.g., the relation between thermodynamic constants for diatomic gases (which is different from that for other gases). We can define the corresponding parameters separately in TOML files; relying on users to define them consistently. (I.e., we do not want to hard-code assumptions that we only simulate diatomic atmospheres.)

[tapios]

(Being able to specify expressions in the TOML file would be nice. But I'm concerned that an attempt of making something maximally flexible delays getting something to work.)

[simonbyrne]

One additional note: we are talking about parameter defaults being defined in terms of other parameter defaults here right?

It could be a functional relationship (see my point 2 above), but that depends on how we implement it.

[odunbar]

An update: given the new proposal, see the comments in the thread of #59.

The likely way this would be handled in the proposal is within the Microphysics component. E.g. a parameter structure for a model component will be created as follows (using the old naming conventions as above).

struct MicrophysicsComponent 
    #parameters used directly in Microphysics:
    ρ_cloud_ice
    r0_ice
    me_ice
    ... 
    #derived parameters
    m0_ice
    ...
    #subcomponents
    Thermodynamics
    ....
end

#Example Constructor
function MicrophysicsComponent(paramset) 
    #create the derived parameter definitions
    m0_ice = /3 * π * paramset.ρ_cloud_ice * paramset.r0_ice^paramset.me_ice 
    ...
    new MicrophysicsComponent(ρ_cloud_ice, r0_ice, me_ice, ..., m0_ice, ...)
end

On construction of the component micro::MicrophysicsComponent, one will refer to any constant as e.g.,

function get_ice_stuff(micro::MicrophysicsComponent,...)
    return micro.m0_ice, micro.r0_ice
end 

The different values in paramset, can also lead to different constructions of the struct, which may help with the flexibility.