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 NEON lightning file deeper into the build-namelist system #2027

Closed
ekluzek opened this issue Jun 16, 2023 · 4 comments
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

To save download time for NEON sites, we've set a file constructed to just contain the range of lat/lons for NEON sites that we use. This has been set in the NEON user-mods and has always been done. The problem with this is that it then bypasses some of the other logic that determines if the lightning file is even needed. For example for SP cases, or if you are running FATES without fire on, or when lightning ignitions aren't taken into account.

Since, NEON has proven to be a critically important capability of the system it would be good to embed the setting of the lightning file into the build-namelist logic alongside the other logic that controls whether it's needed or not. I think this will make the code paths a bit easier to follow.

There are also some downsides of user-mods where they preserve previous code versions when you clone cases in a newer version, this removes that issue.

@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

Some discussion on this is here: #2015 (comment)

@ekluzek
Copy link
Collaborator Author

ekluzek commented Jun 16, 2023

This does help with duplication of user-mods: #1949

I also realized that I currently can't test if the lightning file is correctly set, in the build-namelist unit tester, since the user_mod_clm file is modified by the user-mod with shell_commands. The logic in the shell_commands is a bit messy and simplifying that would be a good thing to do.

We think this would be something clearly good to do, and could be done now. It does line up with the logic in namelist_defaults to do it this way. It entails adding another resolution for NEON, and adding NEON to the current logic, so does slide in nicely.

@ekluzek
Copy link
Collaborator Author

ekluzek commented Jun 16, 2023

The bulk of doing this is adding something like these changes into namelist_defaults:

diff --git a/bld/namelist_files/namelist_defaults_ctsm.xml b/bld/namelist_files/namelist_defaults_ctsm.xml
index 6bb5d60aa..2f7a4e316 100644
--- a/bld/namelist_files/namelist_defaults_ctsm.xml
+++ b/bld/namelist_files/namelist_defaults_ctsm.xml
@@ -1672,6 +1672,7 @@ use_crop=".true.">lnd/clm2/surfdata_map/ctsm5.1.dev052/landuse.timeseries_mpasa1
 <light_res    use_cn=".true." phys="clm4_5"        >94x192</light_res>
 <light_res    use_cn=".true." phys="clm5_0"        >94x192</light_res>
 <light_res    use_cn=".true." phys="clm5_1"        >360x720</light_res>
+<light_res    use_cn=".true." neon=".true."        >106x174</light_res>
 <light_res    use_fates=".true."                         >none</light_res>
 <light_res    use_fates=".true." fates_spitfire_mode="0" >none</light_res>
 <light_res    use_fates=".true." fates_spitfire_mode="1" >none</light_res>
@@ -1679,12 +1680,18 @@ use_crop=".true.">lnd/clm2/surfdata_map/ctsm5.1.dev052/landuse.timeseries_mpasa1
 <light_res    use_fates=".true." fates_spitfire_mode="3" >360x720</light_res>
 <light_res    use_fates=".true." fates_spitfire_mode="4" >360x720</light_res>
 <light_res    use_fates=".true." fates_spitfire_mode="5" >360x720</light_res>
+<light_res    use_fates=".true." fates_spitfire_mode="2" neon=".true.">106x174</light_res>
+<light_res    use_fates=".true." fates_spitfire_mode="3" neon=".true.">106x174</light_res>
+<light_res    use_fates=".true." fates_spitfire_mode="4" neon=".true.">106x174</light_res>
+<light_res    use_fates=".true." fates_spitfire_mode="5" neon=".true.">106x174</light_res>
 
 <stream_year_first_lightng >0001</stream_year_first_lightng>
 <stream_year_last_lightng  >0001</stream_year_last_lightng>
 
 <stream_fldfilename_lightng hgrid="94x192"    >atm/datm7/NASA_LIS/clmforc.Li_2012_climo1995-2011.T62.lnfm_Total_c140423.nc</stream_fldfilename_lightng>
 <stream_meshfile_lightng    hgrid="94x192"    >atm/datm7/NASA_LIS/clmforc.Li_2012_climo1995-2011.T62_ESMFmesh_cdf5_110621.nc</stream_meshfile_lightng>
+<stream_fldfilename_lightng hgrid="106x174"   >atm/datm7/NASA_LIS/clmforc.Li_2016_climo1995-2013.360x720.lnfm_Total_NEONarea_c210625.nc</stream_meshfile_lightng>
+<stream_meshfile_lightng    hgrid="106x174"   >atm/datm7/NASA_LIS/ESMF_MESH.Li_2016.360x720.NEONarea_cdf5_c221104.nc</stream_meshfile_lightng>
 <stream_fldfilename_lightng hgrid="360x720"   >atm/datm7/NASA_LIS/clmforc.Li_2016_climo1995-2013.360x720.lnfm_Total_c160825.nc</stream_fldfilename_lightng>
 <stream_meshfile_lightng    hgrid="360x720"   >atm/datm7/NASA_LIS/clmforc.Li_2016_climo1995-2013.360x720_ESMFmesh_cdf5_150621.nc</stream_meshfile_lightng>
 

@ekluzek
Copy link
Collaborator Author

ekluzek commented Jun 22, 2023

Done in ctsm5.1.dev129

@ekluzek ekluzek closed this as completed Jun 22, 2023
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

No branches or pull requests

1 participant