Open mnlevy1981 opened 2 months ago
Neither Q_RESCALE_POWER = 10
nor R_RESCALE_POWER = 10
show log differences, so it's just T
, L
, C
, and S
.
There is a new pull request (https://github.com/NOAA-GFDL/MOM6/pull/620, that is headed to main via dev/gfdl) that might partially address this issue. It corrects some bugs (including dimensional rescaling factors involving Z and L) in the calculation of the MEKE source terms in a form that I believe is being used at NCAR.
There is a second recent pull request (https://github.com/NOAA-GFDL/MOM6/pull/601, also headed to main via dev/gfdl) that adds comments noting several dimensional inconsistencies within vertFPmix()
and also some checksums that are missing the appropriate scale
arguments. This PR notes the problems but does not correct them because we are not using this subroutine at GFDL, and we wanted to leave it to NCAR to decide how best to correct these issues (e.g., with a ..._BUG flag or just fix them) with minimal disruptions to your ongoing MOM6 simulations.
I suspect that these two pull requests might go a long way toward addressing this issue.
Thanks @Hallberg-NOAA, this is very helpful! Since these issues are only in the chksum
output and don't affect ocean.stats
or what is written to history files, the CESM-based dimensional scaling tests all pass. I think this means (1) we're happy to fix things inline without a _BUG
flag, and (2) this is a fairly low priority, so I'm happy to wait for a few updates to trickle onto dev/ncar
from dev/gfdl
before (eventually) fixing issues noted in https://github.com/NOAA-GFDL/MOM6/pull/601
I got the MARBL branch to pass dimensional scaling tests, but in doing so I noticed that some of the scaling tests are producing
chksum()
differences for non-MARBL fields. My testing strategy was to run a baseline withDEBUG=True
, and then run individual tests withDEBUG=True
and one of the*_RESCALE_POWER=10
. Theocean.stats
files matched for all these runs, but some ofcesm.log
files reported differences in the log output:T_RESCALE_POWER = 10
:L_RESCALE_POWER = 10
C_RESCALE_POWER = 10
S_RESCALE_POWER = 10
Z_RESCALE_POWER = 10
: no diffs in log outputH_RESCALE_POWER = 10
: no diffs in log outputI did not see these differences when running single-column MARBL tests using
solo_driver
, but it's not clear whether that means the missing scaling is in the NUOPC cap or if it has to do with the different parameterizations we are using. Given the bit-for-bit history file output, though, it does seem likely that the problem is a missingscale
argument in thehchksum()
call rather than an actual scaling issue (although the MEKE diff not showing up until the checksum is confusing)