ctsm5.4.039: add new fates namelist switch for dbh init when nocomp is on

[mvdebolskiy]

Description of changes

This change is coordinated with FATES PR NGEET/fates#1550.

Adds a switch for initializing patches with dbh instead of density for nocomp runs.

Specific notes

Contributors other than yourself, if any:

CTSM Issues Fixed (include github issue #):

Are answers expected to change (and if so in what way)?

No, switch is off by default

Any User Interface Changes (namelist or namelist defaults changes)?

use_fates_dbh_ini is added.

Does this create a need to change or add documentation? Did you do so?

Testing performed, if any:

ERS_D_Ld20.f45_f45_mg37.I2000Clm60FatesCrujraRs.derecho_intel.clm-FatesColdTwoStreamNoCompFixedBioGeo

Passed with diffs when use_fates_dbh_init=.true.
Without that namelist change bfb.

NOTE: Be sure to check your coding style against the standard
(https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines) and review
the list of common problems to watch out for
(https://github.com/ESCOMP/CTSM/wiki/List-of-common-problems).

[glemieux]

Per the ctsm-fates standup this morning, @mvdebolskiy is going to add a test for the new namelist option that will update the fates_recruit_init_seed on the fly.

[mvdebolskiy]

@glemieux Should I also add an SP test?
I have ERS_D_Ld10.f45_f45_mg37.I2000Clm50FatesCruRsGs.derecho_intel.clm-FatesColdNoCompInitDbh in the queue right now. Will let you know if it goes through.
Test passed.

[glemieux]

@glemieux Should I also add an SP test?

Not at this point, I think. It currently wouldn't end up doing anything since during initialization fates sp mode calculates the initial dbh from a hard-coded height value:
https://github.com/NGEET/fates/blob/b17b0bdff243c6782414e191736fb0d15935a5c7/main/EDInitMod.F90#L1349-L1381

Maybe there is a case to allow the user to change this initial dbh directly instead of calculating it from using the satellite phenology data, but I don't think so (at least not at this point). It would also require a bit of refactor to the sp mode initialization calls. CC'ing @adrifoster for her thoughts.

[glemieux]

Starting fates regression testing.

[glemieux]

aux_clm testing on derecho and izumi is underway.

[glemieux]

Regression testing on izumi is complete and all expected tests are B4B.

Results: /scratch/cluster/glemieux/ctsm-tests/tests_0511-103843iz

I've updated the ctsm5.4.039 baseline on izumi with read permissions.

[ekluzek]

We should add a failure test for this in the build-namelist tester.

[glemieux]

I've got this updated and tested on derecho; I'll push it once it's back online.

[ekluzek]

It looks like jobs on Derecho timed out. But, the following ones are listed as pending still:

ERS_D.f19_g17.I1850Clm50BgcCrop.derecho_intel.clm-ciso_monthly_matrixcn_spinup
PEM_D_Ld5.ne30_g17.I2000Clm50BgcCru.derecho_intel.clm-default
SMS_Ln9.ne30pg2_ne30pg2_mg17.I1850Clm50Sp.derecho_intel.clm-clm50cam6LndTuningMode--clm-nofireemis
SMS_Ln9.ne30pg2_ne30pg2_mg17.I2000Clm50BgcCrop.derecho_intel.clm-clm50cam6LndTuningMode

Izumi all looks fine. I didn't check the fates tests.

[ekluzek]

There's a simple change to add a test to the build-namelist tester.

A bigger thing that I think would be worth thinking about is how this option should work with finidat files. If I understand this right this only applies if CLM_FORCE_COLDSTART==off. If that's the case we might want to add some more checking around this. I think that might be easy to do, but we'd probably want to it in a different PR since the testing is almost complete here. I can make an issue around this and it could be something for b4b-dev in the next go around.

[mvdebolskiy]

@ekluzek this is only used in coldstart. (you can check call sequence in fates: init_cohorts->init_patches->init_coldstart none of which are called when finidat is used. It has no effect on finidat files. Also, I don't think there is a test needed, since there is NGEET/fates#1558. Which will cause us to remove the condition.

[ekluzek]

@ekluzek this is only used in coldstart. (you can check call sequence in fates: init_cohorts->init_patches->init_coldstart none of which are called when finidat is used. It has no effect on finidat files. Also, I don't think there is a test needed, since there is NGEET/fates#1558. Which will cause us to remove the condition.

I looked through both the new code you pointed to and the old code. Yes, the code will ignore this setting if a restart or finidat file is provided. But, that can cause the user to not realize what's going on with the model at startup. They might think they are using DBH for initialization -- but the finidat file is really being used.

What I'm suggesting is that in the namelist code we make sure that use_fates_dbh_init can ONLY be set to true if it's a coldstart. This makes it more obvious that use_fates_dbh_init is only used for initiatlization only when initial conditions aren't provided.

Personally I strongly prefer that I find out at build-namelist time that the namelist items I asked for are incompatible. Neither of the alturnatives of silently doing the wrong thing, or ignoring what the user asks for are good solutions to me. Especially with the diverse set of users for the model that include people that know next to nothing about CTSM.

[ekluzek]

I created an issue for the thing that I should be added in. It can come in in a future tag, and could be made in b4b-dev in the go around after this one.

#4022