-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
maintaining parameter sets for testing with different HLMs #761
Comments
on second thought... maybe I will use python for the script since that is more machine agnostic. It might be a more useful script for others... |
Right, so ELM will have a script to make the required changes to the default? That would be cool. I feel like this might have (had) lots of potential other uses if it works out. |
working on a prototype here: This system uses a script that reads in an xml file that defines:
The script will convert cdl (text) to binary, then call existing scripts ../tools/FatesPFTIndexSwapper.py and ../tools/modify_fates_paramfile.py to make the changes. And then dump the result back to cdl format. This might make it easier for people to keep track of and share what they have changed. Here is an example of the set of changes to create and e3sm test parameter file: Here is the driver script that pulls everything together: https://github.com/rgknox/fates/blob/mod-e3sm-testparam/tools/BatchPatchParams.py |
@rgknox - very cool prototype to be e3sm specific. There are a couple vcmax25 specific parameters that should go into the ELM centric parameter file, becuase they are related to ECA (and thus not used in ctsm). They are "fates_eca_vcmax_np1", np2, np3, and np4. Coefficients used in the equation 18 in Qing's paper (https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2018MS001571) that calculates photosynthesis as a fuction of leaf N. I'm working to create a more new nutrient constrained photosynthesis branch, that is based off of your https://github.com/rgknox/E3SM/tree/rgknox/lnd%2Ffates-cnp. I think this is your most up-to-date parteh branch correct? Hopefully can share this soon. |
@jenniferholm - thanks for the interest I'm hoping these xml style diff files will be useful to people in various contexts. The file I posted is targeting the changes required to run the E3SM test suite on fates master, so it doesn't have the capability to add new parameters that are not in the base parameter file. However, that is an interesting idea. I suppose the scripts could be expanded to enabled that functionality. It would require more information to be added to the xml: about the dimensions, and perhaps the metadata of the parameter, but i suppose it could be done. |
Ahh. There are already a handful of "eca" specific parameters in the default parameter file. Do you think it's better to just add these 4 additional parameters to the default file? Instead of using a script to add in HLM specific parameters? (Because maybe this is overly complicating things.....) |
I think with the implementation of any new hypothesis, there is this point in the development where we become sure enough of the long-term viability of any new parameter's use and the ultimate form we want it to take. While working out the allocation and uptake parameters, they changed on me a few times (e.g. the storage parameters aren't defined by stoichiometries anymore, and are now ratios with other tissues total mass). So I don't know, maybe we have a check-in/discussion on this stuff to help road-map it? |
With FATES-CTSM, when we want to test N & P cycling through FATES, our only option (since fates-ctsm does not have a fully coupled nutrient cycle) is to prescribe uptake, ie (fates_prescribed_nuptake > 0 and fates_prescribed_puptake > 0). Thus the default in the fates parameter file is fates_prescribed_*uptake = 1. If this is not > 0, fates plants will not receive any N or P and thus the test of FATES' capabilities is meaningless.
However, with FATES-ELM, we do NOT want to prescribe uptake when we want to test the cycling N and P, because the two models are fully coupled, the uptake is emergent. If fates_prescribed_*uptake is > 0, we can't really test the fully coupled nature of the two models. When the parameter is set to zero, it signals to fates to provide all the correct boundary conditions to ELM in order to compete for nutrients in the soil.
I think my solution (for the time being) is to store the testing binary (.nc) of the parameter file with ELM to contain the modification that sets fates_prescribed_*uptake = 0, which is a slight divergence from what we have tracked in version control. I will track this with a bash script that stores the modifications and calls tools/modify_fates_paramfile.py
The text was updated successfully, but these errors were encountered: