Some variables in ED2 config.xml set to 0 when no data in ensemble samples

[Aariq]

Bug Description

For some variables, when there is no data for a variable in ens.samples, and no default in PEcAn, the config.xml gets written with a 0 for that tag. For example, the ensemble samples for temperate.Early_Hardwood doesn't have a column for leaf_turnover_rate which results in a config.xml with <leaf_turnover_rate>0</leaf_turnover_rate> (which either means immortal leaves or undead leaves??).

I think this is happening in write.config.xml.ED2() where some of the defaults in the history data file are 0 for leaf turnover rate.

To Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

I believe leaving a tag out of the config.xml uses whatever the ED2 default is for the PFT. Maybe that's more sensible for some (or all) variables?

[Aariq]

@dlebauer this isn't quite a bug after all. It looks like 0 is a default for leaf turnover rate from history.csv. Are we sure this isn't sensible?

[mdietze]

Given that this is a deciduous PFT, assuming that leaf turnover is 0 outside of the phenological transitions isn't a bad first approximation. 0 would only produce immortal leaves for evergreen PFTs

[Aariq]

Ok, that makes sense. We're getting some weird results like increases in NPP of 10 orders of magnitude for a single month with some ensemble members of runs and grasping at straws a little trying to figure out what's going on. Why do we use the defaults in history.csv to write tags in config.xml instead of just leaving them blank and using ED2 defaults?

[mdietze]

history.csv contains the ED2 defaults. We overwrite all of the ED2 defaults because of the risk of PFT mismatch (e.g. if you wrote your a new decidiuous tree PFT into the PFT 1 slot in ED2 and that previously was a tropical grass then the ED2 "defaults" in that slot would be a very bad choice). PEcAn allows you to create new PFTs, not just calibrate the ones that are built in, which potentially includes having 2+ PFTs that use the same "parent" default, meaning they can't both be written into the parent's default slot.

In terms of debugging a 10^10 increase in NPP, that's unusual even for ED2. Have you tried running the model with its default parameters to isolate parameter errors from errors in drivers or IC? If you've isolated the issue to parameters, have you tried running a SA to determine which parameters are causing such large increases?

[Aariq]

Yeah, that makes sense. But why use history.csv to contain the ED2 defaults? From the ED2 wiki, and a discussion I had over there, it sounds like you can just leave parameters out of config.xml to use ED2 defaults. This would reduce a lot of complexity in the PEcAn.ED2 package and reduce the risk of defaults in history.csv not matching updates to ED2. Like, the machinery to pick the correct history.csv based on the pecan.xml <revision> tag is currently broken, so it would be great if we could just not rely on these files.