Closed MostafaGomaa93 closed 11 hours ago
@MostafaGomaa93 please consider adding those variables to the config file, see config_file_template.txt instead of input.xlsx
. The format xlsx
is proprietary and it is not recommended according to FAIR data principles.
Also, using config_file_template.txt
, makes it easier to set up parameters using python interface in pystemmusscope.
@SarahAlidoost Is there another option than the config_file? just thinking because the config file is all about the path to the data folders, and no variables are assigned in it.
@SarahAlidoost Is there another option than the config_file? just thinking because the config file is all about the path to the data folders, and no variables are assigned in it.
Currently variables like “Location”, “startTime” and “endTime” are also in the config_file_template. The idea of having one configuration file is to follow community standards for coupling models: a config file should be used to setup
a model (see PyMT definition) or initialize
a model (see BMI definition). model.setup
usually creates a working directory and finds the data based on the information in the config file.
For stemmus_scope, it would be great to merge all configurations (IO directories) and tunable parameters (getModelSettings
and input.xlsx
, hardcoded values) into one file. This way, users are able to reproduce/reuse a workflow by changing one file instead of several files. In addition, having one file makes the development and maintenance easier.
I agree that it is better to separate directories from parameters, like by creating sections in a yaml file. However, it requires changing the format of txt
to yaml
and updating the reading and writing functions in stemmus_scope and pystemmusscope. For more info, see an example of yaml file to run zampy.
Thanks for the explanation @SarahAlidoost. I indeed agree with you about having one file for all settings and parameters. In the meantime, can we do it through the BMI? if agreed, I can add these two variables to the BMI table (here). I will also make a very slight change in the source code.
I already discussed the idea with @yijianzeng and he agreed.
Thanks for the explanation @SarahAlidoost. I indeed agree with you about having one file for all settings and parameters. In the meantime, can we do it through the BMI? if agreed, I can add these two variables to the BMI table (here). I will also make a very slight change in the source code.
I already discussed the idea with @yijianzeng and he agreed.
yes, it can be added to the BMI implementation. But the initial values of these two variables should be defined somewhere in the stemmus_scope code.
Thanks for the explanation @SarahAlidoost. I indeed agree with you about having one file for all settings and parameters. In the meantime, can we do it through the BMI? if agreed, I can add these two variables to the BMI table (here). I will also make a very slight change in the source code. I already discussed the idea with @yijianzeng and he agreed.
yes, it can be added to the BMI implementation. But the initial values of these two variables should be defined somewhere in the stemmus_scope code.
Yes, the defalut values are already there in the code.
Thanks for the explanation @SarahAlidoost. I indeed agree with you about having one file for all settings and parameters. In the meantime, can we do it through the BMI? if agreed, I can add these two variables to the BMI table (here). I will also make a very slight change in the source code. I already discussed the idea with @yijianzeng and he agreed.
yes, it can be added to the BMI implementation. But the initial values of these two variables should be defined somewhere in the stemmus_scope code.
Yes, the defalut values are already there in the code.
The variables added to the table here are in the structure ModelSettings
. Currently, model settings are loaded in different scripts as ModelSettings = io.getModelSettings();
, see search results. Therefore, it is not possible to update the variables of ModelSettings
through BMI because calling io.getModelSettings()
will reset the values again. We need a workaround for this. @BSchilperoort what do you think?
Notices to be considered
I have done several tests in changing the total soil depth (getModelSettings.Tot_Depth
). To avoid errors in the model run, the following need to be considered:
getModelSettings.Tot_Depth
= 300 cm. This is because of the structure of the Dtrmn_Z
function. In the future releases, if we want to change the getModelSettings.Tot_Depth
to be < 300, then the Dtrmn_Z
will need to be adjusted.getModelSettings.Tot_Depth
= 1400 cm. That is because the maximum number of soil layers getModelSettings.NL
= 100. So, if we want to let getModelSettings.Tot_Depth
> 1400 cm, the getModelSettings.NL
will need to be > 100.
Currently, the soil total thickness is fixed to 5 m in the
getModelSettings
(here). Same also for the depth of the root zone is fixed to 3.5 m (here). I believed that these two values can be changed from one site to another and also with different landcover, so in my opinion, it would be more convenient for the user if we can change these two values outside the code (through one of the input files).Suggestion solution We can add these two to the sheet
input.xlsx
and the user can change them from that sheet. Then, the value will be updated in the code (here)What do you think @yijianzeng and @bobzsu? If agreed, I am willing to do this adjustment and update the code with @SarahAlidoost