remove duplicate config variables in ocean #4907
Conversation
|
This should not impact other MPAS components and I did build sea-ice successfully, but haven't run any tests with the other components to verify. |
|
@philipwjones - who can review this PR? I requested @mark-petersen but please let me know if you think anyone else should look at it |
|
@philipwjones - testing of a merge of this failed in E3SM with the following error messages: |
removes the duplicate config scalars (varinp_name) that were introduced in a previous commit for safety when adding the get_config_scalar routine
|
@jonbob - yeah, I guess that was added after I submitted this PR. I'm rebasing and fixing some deprecated stuff in the SAL routines. Should have some updates pretty quick. |
…oading
removed/replaced meshPool and configPool retrievals since info
available through module use statements
removed a block loop since multiple blocks no longer supported
|
Thanks @philipwjones - I figured it had to be something like that |
philipwjones
force-pushed
the
philipwjones/mpas-framework/fix-config-dup
branch
from
fc87c1e
to
e07709c
Compare
|
Ok @jonbob this should work now |
|
@philipwjones - it's not clear to me if this PR should be BFB for our typical E3SM tests. The documentation says it shouldn't be on Intel but it's not clear under what conditions |
|
@jonbob - the non-bfb results were from any standalone case I ran with Intel (at least on Compy, Chrysalis), though I notice the standalone MPAS build uses -O3 while the E3SM build uses -O2. So it's possible this PR will be bfb in E3SM builds with the lower optimization level. |
|
Thanks @philipwjones - I was curious because the PR didn't have a BFB or non-BFB label. So far my tests on chrysalis have been BFB for:
and waiting for:
|
|
Also BFB for SMS_D_Ld1.ne30pg2_r05_EC30to60E2r2.WCYCL1850 using chrysalis_intel |
|
@philipwjones - I thought if you saw non-BFB behavior on compy I'd test there as well. With the default compiler as pgi, an SMS_P12x2.ne4_oQU240.WCYCL1850NS.compy_pgi.allactive-mach_mods test case fails to build with the following error message: |
|
@jonbob - argh, sorry about that. Apparently got sloppy with that last commit and forgot to remove some pointer declarations. Just pushed a fix that builds with Nvidia. |
|
Thanks @philipwjones. It now builds and is BFB on compy, at least for:
I'm waiting for at least one test to run on chrysalis with the newest set of changes and then feel confident to merge as a BFB PR |
#4907) Remove duplicate config variables in ocean Removes the auto-generation of duplicate config scalars (varinp_name) that were introduced in a previous commit for safety when adding the get_config_scalar routine. [BFB]
|
merged to next |
|
merged to master |
Removes the auto-generation of duplicate config scalars (varinp_name) that were introduced in a previous commit for safety when adding the get_config_scalar routine.
This is bit for bit except with Intel which is performing a peculiar optimization in the time_integration_split routine with the config_btr_ weights. When these are pointers you get bit-for-bit with current master, but when they're scalars you get roundoff level changes even though the values of the weights are equivalent. I've been able to reproduce this effect on the current master using a local temp scalar instead of the pointer to demonstrate it's not a bug being introduced.
Note: the non-BFB behavior above was for mpas-o standalone, which uses a different optimization level for intel. Testing in E3SM shows BFB results with current master.
It was bit for bit on other compilers like nvhpc on Summit.
[BFB]