-
Notifications
You must be signed in to change notification settings - Fork 319
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
Refactor to move setting of NEON surface datasets deeper into the build-namelist system #2028
Comments
This also can help with duplication of user-mods: As surface datasets for FATES could be chosen in the namelist defaults logic. @adrifoster and I chatted about this a bit, and we think this one needs more discussion it's less obvious that this is better. |
I experimented to see what this would look like and this is the core part of what it would need in the namelist defaults XML file. There are changes inside of the perl build-namelist to set NEONSITE, and have fsurdat use both NEON and NEONSITE. Also the add_default method would need to expand namelist items as part of it's normal operation, which I think should be fine. If that's done, you can then use $NEONSITE for most cases and only call out the few that diverge from that with an explicit NEONSITE attribute check. As such this seems like a better way to go... +<!-- for NEON sites present day simulations - year 2000 -->
+<fsurdat neon=".true." use_fates=".false.">
+lnd/clm2/surfdata_map/NEON/surfdata_1x1_NEON_$NEONSITE_hist_78pfts_CMIP6_simyr2000_c230601.nc</fsurdat>
+<fsurdat neon=".true." use_fates=".false." neonsite="TOOL">
+lnd/clm2/surfdata_map/NEON/surfdata_1x1_NEON_TOOL_hist_78pfts_CMIP6_simyr2000_c230699.nc</fsurdat>
+<fsurdat neon=".true." use_fates=".true.">
+lnd/clm2/surfdata_map/NEON/16PFT_mixed/surfdata_1x1_NEON_$NEONSITE_hist_16pfts_Irrig_CMIP6_simyr2000_c230120.nc</fsurdat>
+ |
… connected, fixing ESCOMP#2028
…aving res be CLM_USRDAT when clm_usr_name option is set and setting fsurdat and flanduse in namelist defaults for NEON sites
This is similar to #2027, but not as obvious as something needed to do. Right now NEON surface datasets are set using user-mods. We have a line that gives the creation dates for all NEON files and we update all files even when we only need one to be updated. We also have a separate copy of this setting for FATES.
If we refactor to move this to inside of namelist_defaults, we could easily have a line for each site. Which would make it easily possible to change date stamps for individual sites. And the logic for FATES could be embedded at that level as well. Which would remove some of the need to replicate the user-mods for FATES.
The downside of creating all files isn't too bad, since these datasets are small. But, for dataset providence it would be beneficial to only update the datasets that really need to, so then you can understand the history of needed changes more clearly.
The text was updated successfully, but these errors were encountered: