Open mnlevy1981 opened 6 years ago
From #334 --
Many GCMs will define T0_Kelvin
and K_Boltz
for non-MARBL computations. For consistency, we should provide a way for the GCM to tell MARBL what these values are. Options:
marbl_instance%init()
marbl_instance%set_global_constants()
(or set_physical_constants()
?) that can be called before init()
marbl_settings_mod.F90
and use marbl_instance%put_setting()
I don't really like this last option because I don't know that we want users to be able to override the GCM value without editing the Fortran. I'm leaning towards the second option, where set_global_constants()
is treated like put_setting()
but without a file like user_nl_marbl
to allow run-time configuration.
Note: POP could then populate these fields with values from share code (note that #328 wants K_Boltz
in eV/K
rather than J/K
so POP would need to do the unit conversion)
The following parameters are defined in
marbl_constants_mod.F90
, but used in POP:If there was a data type similar to
marbl_settings_type
that allowed users to runget()
, then we could eliminate theuse marbl_constants_mod
statements. In talking about this, though, @klindsay28 and I realized that there are a number of "constants" that are currently defined with Fortran'sparameter
attribute that we may want to allow the GCM to override:One possibility would be to move these variables to
marbl_settings_mod
, but this would require a change indefault_settings.yaml
(and the associated Python code) to avoid putting the default value inmarbl_in
: I envision the GCM callingput_setting()
with its desired value, and then only over-writing that with a secondput_setting()
call if the user explicitly specified a different value in the MARBL input file. Having a value in the input file by default would mean the GCM's preference would always be ignored.Note it might also be useful to include
c14_halflife_years
frommarbl_ciso_mod.F90
.