Merge in DoD onyx mods #3100
Merge in DoD onyx mods #3100
Conversation
| @@ -8446,4 +8446,78 @@ | |||
| </pes> | |||
| </mach> | |||
| </grid> | |||
| <grid name="a%T62.+oi%oARRM60to10|a%TL319.+oi%oARRM60to10"> | |||
There was a problem hiding this comment.
I would suggest to add these changes for a specific machine. Also, @apcraig: we should talk about the improvements you experienced with these settings (we can do this by email).
There was a problem hiding this comment.
Good idea. I will take care of that.
| @@ -440,14 +442,20 @@ | |||
| <config_use_activeTracers>.true.</config_use_activeTracers> | |||
| <config_use_activeTracers_surface_bulk_forcing>.true.</config_use_activeTracers_surface_bulk_forcing> | |||
| <config_use_activeTracers_surface_restoring>.false.</config_use_activeTracers_surface_restoring> | |||
| <config_use_activeTracers_surface_restoring ocn_grid="oARRM60to10">.true.</config_use_activeTracers_surface_restoring> | |||
| <config_use_activeTracers_surface_restoring ocn_grid="oARRM60to6">.true.</config_use_activeTracers_surface_restoring> | |||
There was a problem hiding this comment.
these should not be default because we only do restoring in G-cases.
There was a problem hiding this comment.
I will back out all of the changes to the mpaso namelist_defaults. I think that is more consistent with the overall strategy of using user_nl_mpaso to set things up and the benefit is the namelist defaults file remains consistent with master.
| <config_use_activeTracers_interior_restoring>.false.</config_use_activeTracers_interior_restoring> | ||
| <config_use_activeTracers_exponential_decay>.false.</config_use_activeTracers_exponential_decay> | ||
| <config_use_activeTracers_idealAge_forcing>.false.</config_use_activeTracers_idealAge_forcing> | ||
| <config_use_activeTracers_ttd_forcing>.false.</config_use_activeTracers_ttd_forcing> | ||
| <config_use_surface_salinity_monthly_restoring>.false.</config_use_surface_salinity_monthly_restoring> | ||
| <config_use_surface_salinity_monthly_restoring ocn_grid="oARRM60to10">.true.</config_use_surface_salinity_monthly_restoring> | ||
| <config_use_surface_salinity_monthly_restoring ocn_grid="oARRM60to6">.true.</config_use_surface_salinity_monthly_restoring> |
There was a problem hiding this comment.
same comment as above
There was a problem hiding this comment.
same comment as above.
| @@ -28,7 +28,8 @@ add_default($nl, 'config_full_abort_write'); | |||
| # Namelist group: decomposition # | |||
| ################################# | |||
|
|
|||
| add_default($nl, 'config_block_decomp_file_prefix', 'val'=>"'${DIN_LOC_ROOT}/ice/mpas-cice/${ICE_GRID}/mpas-cice.graph.info.${date_stamp}.part.'"); | |||
| #add_default($nl, 'config_block_decomp_file_prefix', 'val'=>"'${DIN_LOC_ROOT}/ice/mpas-cice/${ICE_GRID}/mpas-cice.graph.info.${date_stamp}.part.'"); | |||
| add_default($nl, 'config_block_decomp_file_prefix', 'val'=>"'${DIN_LOC_ROOT}/ice/mpas-cice/${ICE_GRID}/mpas-seaice.graph.v2.${date_stamp}.part.'"); | |||
There was a problem hiding this comment.
could you please explain this change? Shouldn't the default be the graph.info file since we do not know for sure if the v2 version is available for all meshes?
There was a problem hiding this comment.
I have reviewed this and will remove it. I just grepped for graph in the mpas-seaice stuff and made changes in all places that seemed appropriate. I have now looked at the implementation and agree this should be left unchanged.
|
@rljacob , @jgfouca . This is a PR from one branch to another. I don't think we need E3SM in general involved. @milenaveneziani and I are discussing and taking care of it. I hope we are not breaking any E3SM process by using PRs. It's cleaner and easier that pushing directly as it provides an opportunity for multiple people to review easier. Thanks. |
|
@apcraig , I didn't notice that. I have reassigned to @milenaveneziani |
|
I didn't notice that either. We really don't want these kind of PRs appearing in our backlog. You should do them on a fork instead. |
|
@milenaveneziani , what do you think about the process? Should we move the branch to a branch on a fork? Or should we avoid PRs in the future and just push to the E3SM branch as needed? I think PRs are a nice way to merge that provides some additional features over just pushing. But willing to use whatever process you prefer. |
|
I think we should move it to a fork. I can push the branch to your fork and we can start again there? |
|
@apcraig: I have pushed this branch to my fork. I will close this now. |
…un-eamxx-workflows Always run eamxx workflows on PRs
Port to onyx.
Updates default pe layout for ARRM 60to10 and 60to6 configurations.
Updates default mpas-ocean namelist for ARRM 60to10 and 60to6 configurations