The config holds nice info on model config parameters: title, unit, et cetera. This is used in the config form.
There are related bmi parameters: get_input_var_names and get_output_var_names. Both are simply lists of strings, without all the nice metadata available in the config. A shame. To still use the config metadata in the web app, I would like to make sure the values from get_input_var_names and get_output_var_names correspond to values in the config.
Concerning get_input_var_names: some config parameters are also state variables. They are currently grouped under initialState group. E.g. initialState.theta0 is initialized as model.theta. We could change the config to initialState.theta instead.
Concerning get_output_var_names: historically, CLASS has always included all config parameters, not just model state. This may be useful when you compare two runs where one uses a fixed value for (e.g.) radiation and another a dynamically computed variable (this depends on the settings). Perhaps it would make sense to have an additional metadata field include_in_output in the config, so we could get parameter names from filtering the config and additional metadata?
Question: in the config, options are nested in groups, e.g. MixedLayer.wtheta. In previous class versions it was a flat list, so let's think about how to deal with it here.
The config holds nice info on model config parameters: title, unit, et cetera. This is used in the config form.
There are related bmi parameters:
get_input_var_namesandget_output_var_names. Both are simply lists of strings, without all the nice metadata available in the config. A shame. To still use the config metadata in the web app, I would like to make sure the values fromget_input_var_namesandget_output_var_namescorrespond to values in the config.Concerning
get_input_var_names: some config parameters are also state variables. They are currently grouped underinitialStategroup. E.g.initialState.theta0is initialized asmodel.theta. We could change the config toinitialState.thetainstead.Concerning
get_output_var_names: historically, CLASS has always included all config parameters, not just model state. This may be useful when you compare two runs where one uses a fixed value for (e.g.) radiation and another a dynamically computed variable (this depends on the settings). Perhaps it would make sense to have an additional metadata fieldinclude_in_outputin the config, so we could get parameter names from filtering the config and additional metadata?Question: in the config, options are nested in groups, e.g.
MixedLayer.wtheta. In previous class versions it was a flat list, so let's think about how to deal with it here.