Skip to content
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

Closed
ekluzek opened this issue Jun 16, 2023 · 2 comments · Fixed by #2044
Closed
Assignees
Labels
code health improving internal code structure to make easier to maintain (sustainability)

Comments

@ekluzek
Copy link
Collaborator

ekluzek commented Jun 16, 2023

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.

@ekluzek ekluzek added the code health improving internal code structure to make easier to maintain (sustainability) label Jun 16, 2023
@ekluzek ekluzek self-assigned this Jun 16, 2023
@ekluzek
Copy link
Collaborator Author

ekluzek commented Jun 16, 2023

This also can help with duplication of user-mods:

#1949

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.

@ekluzek ekluzek added the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Jun 16, 2023
@ekluzek
Copy link
Collaborator Author

ekluzek commented Jun 18, 2023

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>
+

@billsacks billsacks removed the next this should get some attention in the next week or two. Normally each Thursday SE meeting. label Jul 6, 2023
ekluzek added a commit to ekluzek/CTSM that referenced this issue Aug 14, 2023
ekluzek added a commit to ekluzek/CTSM that referenced this issue Aug 14, 2023
…aving res be CLM_USRDAT when clm_usr_name option is set and setting fsurdat and flanduse in namelist defaults for NEON sites
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code health improving internal code structure to make easier to maintain (sustainability)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants