Closed mvertens closed 3 months ago
It looks like this PR contains your other feature/cism2mosart - that makes it difficult to review independently.
I agree. This is why I made it a draft PR. Once the feature/cism2mosart is accepted and I also do the testing - we can remove the draft status.
I haven't looked at the detailed changes here, but support these changes based on discussions with @mvertens . @mvertens please let me know if you'd like my more careful review of any pieces of this.
@mvertens I'm happy to review this, but I need this PR https://github.com/ESCOMP/CMEPS/pull/452 reviewed/merged before I can get ufs working w/ the current main.
@DeniseWorthen merged #452
@jedwards4b Thanks. I'll test the trigrid PR now.
@denise - thanks so much for reviewing this.
@mvertens I'm getting a runtime error in med_internalstate_init at
call NUOPC_CompAttributeGet(gcomp, name='mesh_lnd', value=lnd_mesh_name, rc=rc)
if (ChkErr(rc,__LINE__,u_FILE_u)) return
which gives me
PET000 med_internalstate_mod.F90:247 Invalid argument - Passing error in return code
Can you provide the entire PET log for that error please? And if you ran on derecho a pointer to the case directory. Thanks
Here is the rundir on derecho
/glade/derecho/scratch/worthen/FV3_RT/trigrid/cpld_control_nowave_noaero_p8_intel
It looks like mesh_lnd is expected as a new input variable - but there is no definition in the namelist xml files. @mvertens?
@DeniseWorthen I think it should be defined in ufs.configure
In UFS, we don't usually run land as a separate component. I wonder if we need a 'if comp_present(complnd)'.
@jedwards4b @DeniseWorthen - sorry about that. I fixed this on betzy - but did not push it back and now betzy is down. Let me fix it here.
@jedwards - mesh_lnd is defined in cime_config/namelist_definition_drv.xml:
@DeniseWorthen - I've just pushed a change back. Can you please try again.
@mvertens We also don't have a mesh for ATM, so I made a fix like so
- character(len=CL) :: atm_mesh_name
+ character(len=CL) :: atm_mesh_name=''
to give it a default name. This might not be the best fix.
But then I got a subsequent error in prep_atm
forrtl: severe (408): fort: (2): Subscript #1 of the array FLDNAMES_TO_OCN has value 4 which is greater than the upper bound of 3
Image PC Routine Line Source
fv3.exe 00000000112060BB med_phases_prep_a 214 med_phases_prep_atm_mod.F90
edit: I'm doing my testing in debug. Changing len(fldnames_to_ocn) to size(fldnames_to_ocn,1) works (but why?).
@DeniseWorthen - I've pushed back a change that hopefully addresses the problem you ran into. Could you please give your testing another try?
@mvertens I'm still getting errors (in debug)
forrtl: severe (194): Run-Time Check Failure. The variable 'med_internalstate_mod_mp_med_internalstate_init_$ISPRESENT_LND' is being used in '/glade/work/worthen/ufs_trigrid/CMEPS-interface/CMEPS/mediator/med_internalst\
ate_mod.F90(254,41)' without being defined
@DeniseWorthen - I'm retesting now and I'll fix this. It's unfortunate that I cannot run the UFS test - so I really appreciate your doing this!
@DeniseWorthen - can you please test again.
@mvertens The run-time error is now
forrtl: severe (408): fort: (2): Subscript #1 of the array FLDNAMES_FROM_OCN has value 6 which is greater than the upper bound of 5
Image PC Routine Line Source
fv3.exe 0000000011206FF3 med_phases_prep_a 215 med_phases_prep_atm_mod.F90
@DeniseWorthen - I have pushed a fix back. Please try again.
@mvertens Thanks. Everything is now running at least. Our GNU platforms are unavailable today, so I'll have to wait until tomorrow to do a full test. Is that OK?
@jedwards4b - I'm not sure we were ready to merge yet. @DeniseWorthen still has to do her GNU platform test. For now let's keep it and issue a bug report if @DeniseWorthen finds problems.
That was my thought too. I still have an instance of wav2ocn_smap at line 2991 of esmFldsExchange_cesm_mod.F90 though.
Sorry for delay in testing. The platform (hercules) had an unexpectedly long downtime. I've created an associated issue #475.
Description of changes
Adds capability to run the atm and lnd components on different grids
Specific notes
Original analysis from @billsacks: See section 3.2.3 in https://docs.google.com/document/d/144PZ63gwpz875U4EYEI7NuxnF__V955QJOxV9LcEAL0/edit# (starting on p. 14).
New analysis from @billsacks : It seems like we can get conservation in the glc mappings if we consistently use lfrin in those mappings / merges as well. @billsacks has put some more notes here: https://docs.google.com/document/d/1Npv8njQV1SDwKn2hW35fO2GgE3ciemu4Hqfxg7ZyJKs/edit#heading=h.24mbe68cyqy7
In particular see new notes at the top level of
med_fraction_mod.F90
in this PR.Contributors other than yourself, if any: @billsacks
CMEPS Issues Fixed (include github issue #):
Are changes expected to change answers? bfb as long as atm/lnd are on the same grid, more substantial otherwise (simulations are being carried out for NorESM to validate this)
Any User Interface Changes? No
Testing performed
Using a sandbox that started with cesm3_0_alpha01a and
Verified that the following 2 tests worked were bfb when the trigrid branch was substituted for cmeps0.14.70