Issue with pft parametrization using xml

[hamiddashti]

I'm trying to overwrite pft 12 with my own parameter values. Problem is some of the parameters that are calculated inside ed_params.f90 they use the initial values inside ed_params for the calculations, not the values provided by xml. For example, consider qsw parameter which is defined as (SLA / sapwood_ratio), it is always the same value no matter of what is the value of SLA and sapwood in the xml file. Consider pft 12 in ed_params.f90, the SLA is 22.0 and sapwood is 3900, the qsw is always 0.005641026 (22 / 3900). I changed SLA to 11 in input.xml and it matches with history.xml but the value of qsw is still 0.005641026. Am I missing something here? Thanks

[xiangtaoxu]

Hi, Hamid,

Default values for parameters are all defined in init/ed_params.f90. Some of them are derived parameters, like qsw, which are calculated from other parameters. Currently, the xml file will overwrite the default values but will not re-calculate the derived parameter values. So, for now, you might have to give values for all relevant derived parameters in your input.xml.

Maybe in the future, we can add the functionality to re-derive the parameters that are depedent on other parameters if they are not overwritten in the xml file. @manfredo89 I remember you mentioned something like that during the workshop. Have your worked to tackle this problem?

[mpaiao]

I rewrote ed_params.f90 to make sure derived parameters are initialized after xml. I am trying to include the changes in smaller blocks (so it's easier to track changes) before I make the sequence of pull requests, but this will take a while. In the meantime, feel free to check my fork.

I did not assume qsw is a derived parameter. It is common to represent it in terms of As:Al ratio, but I don't think this is required. For @hamid4965's issue, my suggestion is to calculate qsw externally and provide it in the xml file too.

[mdietze]

Quick follow up: The fundamental design philosophy I used when I made the XML file was that the user is responsible for such parameter calculations. This is because many (if not most) of the existing 'calculations' are in fact empirical correlations not physical constraints, and those empirical correlations can (and in many cases have) been superseded by an improved understanding of how traits relate to one another. We don't want a design that enforces out-of-date correlations when tools like PEcAn provide runtime updates to trait-derived parameters. A few years back @rgknox attempted a similar refactoring to calculate 'derived' parameters, but I ended up shooting it down on these grounds. I'm very interested to see what @mpaiao has worked on, as it sounds like he's making fewer assumptions and making it easier for users to do partial updates.

[hamiddashti]

Thank you everyone. Considering @mdietze comments I think the best approach, for now, is to go ahead and calculate those derived parameters externally. I'm excited to see @mpaiao work on xml as well.