Temporarily add back a T42 dataset for CAM

[ekluzek]

Brief summary of bug

The CAM test

SMS_D_Ln9_Vnuopc.T42_T42.FSCAM.derecho_intel.cam-scam_mpace_outfrq9

fails in cesm2_3_alpha17d and will also fail for the CAM testlist.

General bug information

**CTSM version you are using:**ctsm5.2.0

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

Configurations affected: SCAM

Details of bug

In ctsm5.2.0 we removed support for T42 surface datasets in align with the "Grids in CESM3 document".

Definition of done:

• Create a T42 ctsm5.2.0 2000 dataset
• rimport
• Add it to namelist_defaults in CTSM (hgrid="64x128", for the file labeled T42) [with that as the only change]
• Create a PR with the namelist_default change
• Run a test of SMS_D_Ld1_Mmpi-serial.T42_T42_mg17.I2000Clm50SpRs.derecho_intel.clm-ptsRLA
• Run (or copy from ctsm5.2.002?) aux_clm on izumi/derecho to complete the tag on master

[ekluzek]

We should just add a 2000 surface dataset for this. And we should remove the support for it when CAM no longer needs it.

[slevis-lmwg]

We should just add a 2000 surface dataset for this. And we should remove the support for it when CAM no longer needs it.

@ekluzek for now I will not add this one to the mksurfdata_esmf Makefile because you labeled it "temporary" but maybe the decision depends on when CAM will no longer need it.

[ekluzek]

@slevis-lmwg yes I actually had thought CAM had already moved away from this requirement. But, obviously not. So I've linked this to a CAM issue.

This is also a change they have committed to by CESM3, so I think we just keep this temporary file in place. In ctsm5.3.0 we'll update datasets, but leave this one in place since ctsm5.3.0 will be backwards compatible with ctsm5.2.0 datasets.

[slevis-lmwg]

I generated the new file's namelist using these settings:
./gen_mksurfdata_namelist --res T42 --start-year 2000 --end-year 2000

The new file is ready:
/glade/campaign/cesm/cesmdata/inputdata/lnd/clm2/surfdata_esmf/ctsm5.2.0/surfdata_T42_hist_2000_78pfts_c240425.nc

@ekluzek if this looks good to you, I can ./rimport the file and close this issue.

[ekluzek]

@slevis-lmwg awesome. I did a ncdump -h on the file and it looks great. I Actually neglected to point out other steps that need to be done, as we need a CTSM tag for this that will go into cesm2_3_alpha17f. So I listed those steps at the top.

[slevis-lmwg]

I checked off all the TODOs.
For the last one, I would have chosen "copy from ctsm5.2.002" since we're making a 2-line addition to an .xml file that affects nothing. But making a copy doesn't apply anymore. I just need to merge this to b4b-dev next.

@ekluzek I requested a review from you, in order to merge.

[ekluzek]

In CSEG we figured this will likely come in with cesm2_3_beta17, but it isn't required until cesm2_3_beta18. Since, this is on the b4b-dev branch it will just come in on Thursday.

[ekluzek]

This was done in #2495 and cam in with ctsm5.2.003.