Initialization of historical using CTSM5.4 surface datasets fails

[olyson]

Brief summary of bug

Initialization of a historical simulation that uses CTSM5.4 surface datasets fails because the interpolation can't find an urban tall building district (TBD) landunit in the initial file to interpolate from.

General bug information

CTSM version you are using: ctsm5.3.041

Does this bug cause significantly incorrect results in the model's science? No

Configurations affected: Perhaps all that use an inital file that doesn't have any urban TBD landunits on it.

Details of bug

By design, CTSM5.4 1850 surface datasets don't have an urban TBD landunit present. A spinup using this 1850 dataset thus will not create any urban TBD landunits on the initial (restart) file that results from this spinup. Consequently, a historical simulation that is initialized from this restart file fails with this error message shown below.

Important details of your setup / configuration so we can reproduce the bug

./create_newcase --case /glade/work/wwieder/ctsm5.3.0/ctsm53041_54surfdata_098_HIST --compset HIST_DATM%CRUJRA2024_CLM60%BGC-CROP_SICE_SOCN_MOSART_SGLC_SWAV_SESP --res f09_t232 --run-unsupported

Reproduced with this case:

/glade/work/oleson/ctsm5.3.041/cime/scripts/ctsm53041_54surfdata_098_HIST

To demonstrate this was the problem, I changed one of the landunits on the initial file (changing it from 8 [high density] to 7 [tall building district] - land1d_ityplun, and also changed the associated columns and pfts for that landunit - cols1d_ityplun and pfts1d_ityplun) and that enabled me to get past the error and run 1-month of the historical.
This is a temporary hack. It seems like this should be handled in the initialization code.

Important output or errors that show the problem

dec2415.hsn.de.hpc.ucar.edu 651: ERROR initInterp set_mindist: Cannot find any input points matching output poin
dec2415.hsn.de.hpc.ucar.edu 651: t:
dec2415.hsn.de.hpc.ucar.edu 651: subgrid level, index = pft 469
dec2415.hsn.de.hpc.ucar.edu 651: lat, lon = -0.287842258836760 , 2.55254403104171
dec2415.hsn.de.hpc.ucar.edu 651: ltype: 7
dec2415.hsn.de.hpc.ucar.edu 651: ctype: 71
dec2415.hsn.de.hpc.ucar.edu 651: ptype: 0
dec2415.hsn.de.hpc.ucar.edu 651:
dec2415.hsn.de.hpc.ucar.edu 651: Consider rerunning with the following in user_nl_clm:
dec2415.hsn.de.hpc.ucar.edu 651: init_interp_fill_missing_with_natveg = .true.
dec2415.hsn.de.hpc.ucar.edu 651: However, note that this will fill all missing types in the output
dec2415.hsn.de.hpc.ucar.edu 651: with the closest natural veg column in the input
dec2415.hsn.de.hpc.ucar.edu 651: (using bare soil for patch-level variables).
dec2415.hsn.de.hpc.ucar.edu 651: So, you should consider whether that is what you want.
`

Definition of done:

• Create branch / PR to bfb-dev for the changes
• Run unit-tests to show they work (follow src/README.unit_testing (and run after making small changes)
• Add init_interp_fill_missing_urban_with_HD to appropriate places in the calling tree
• As above rerun unit tests after doing each step...
• Add do_fill_missing_urban_with_HD function
• Add is_urban_HD function similar to is_baresoil
• Add is_urban_landunit function similar to is_vegetated_landunit
• Cut and paste of loop for fill_missing_with_natveg in set_mindist subroutine with similar over urban landunits
• Refactor to consider: The loop for fill_missing_with_natveg in set_mindist mentioned above, should probably be in it's own subroutine. And the same for the new fill_missing_urb_with_HD loop
• Change the endrun call in set_mindist to also mention init_interp_fill_missing_urban_with_HD
• Modify initInterpMindistTestUtils.pf and test_set_mindist.pf to accomodate new code
• Rerun unit tests
• NOTE: Tests in *.pf PF-Unit code have a @test in front of them. They also have @Assert calls to validate the answer is as expected
• Add a new test subroutine to test_setmindist.pf similar to newveg_usesBaresoil. It has two urban landunits, neither of which is TBD, and the output desired is TBD, so it should return the right index if init_interp_fill_missing_urban_with_HD is true
• A new test that verifies that it fails without init_interp_fill_missing_urban_with_HD=.true. could also be added
• Add a new test that verifies that it's not filled because init_interp_fill_missing_with_natveg is true
• The new test should fail
• Get the new test to work fixing Don't allow init_interp_fill_missing_with_natveg to work on urban landunits #3129
• Add init_interp_fill_missing_urban_with_HD to namelist_definiton_ctsm.xml file
• Add f09_FillMissingW_Urban testmod
• Try the SMS_Ld1_D_PS.f09_t232.I1850Clm60SpCrujra.derecho_intel.clm-f09_FillMissingW_Urban test case (show it fails without the new changes, and passes with them)
• Bring the PR to bfb-dev and then to master as normal for a bfb-dev PR

[wwieder]

This issue is more specific about the problems raised in #3107.

[wwieder]

THanks for disgnosing the issue, Keith. I'm curious to hear your thoughts on a solution here? Do you suggest the fix here is to provide a single tall building district on the 1850 surface dataset, or is this something we should change in init_interp to allow to slide by?

[olyson]

Adding a single TBD on the dataset seems a bit hacky long-term (where to put it and why, when it doesn't really exist). It seems like modifying the initInterp code to handle this edge case would be better. If TBD isn't found then initialize from an HD landunit which does exist somewhere, conceptually similar to how init_interp_fill_missing_with_natveg is implemented (if an output type cannot be found in the input, fill with closest natural veg column (using bare soil for patch-level variables)).

[ekluzek]

Yes, thanks for reporting on this and diagnosing the problem @olyson! I like your solution of finding the nearest HD landunit.

If we do this similar to the natveg option. That would be something like adding the namelist item:

init_interp_fill_missing_urban_with_HD

Then it looks like the logic pattern for init_interp_fill_missing_with_natveg could then be followed todo this for any urban landunit to copy the nearest HD.

[ekluzek]

@olyson or @slevis-lmwg if you have time to work on this one, I could go over with you what needs to happen. @wwieder are one of those two the right ones to ask to do this?