Closed gustavo-marques closed 5 months ago
(PS: coordinate settings for hycom1 still need to be done manually)
What would you think about adding a MOM_vert_coord
to env_run.xml
with a default of zstar
but allowing hybrid
as well? Then we could add defaults to MOM_input.yaml
that depend on MOM_vert_coord
and all it would take to switch between zstar and hybrid would be an xmlchange
call.
It might turn out to be a temporary addition to env_run.xml
(if we eventually choose to support one or the other but not both) but I think it would be really useful during this testing phase. We could even use it to support comparing different hybrid coordinates, such as the one proposed by collaborators at U-Miami.
I'm happy to push changes to your branch to test it out.
This pull request modifies the answers, and I have confirmed that we can compare it bit-for-bit with https://github.com/NCAR/omwg_dev/issues/14 without any additional namelist changes.
Do we need to set AUTO_MASKTABLE = False
to be bit-for-bit?
This pull request modifies the answers, and I have confirmed that we can compare it bit-for-bit with NCAR/omwg_dev#14 without any additional namelist changes.
Do we need to set
AUTO_MASKTABLE = False
to be bit-for-bit?
Yes, we do need to set AUTO_MASKTABLE = False
to be bit-for-bit. Thank you for asking that.
(PS: coordinate settings for hycom1 still need to be done manually)
What would you think about adding a
MOM_vert_coord
toenv_run.xml
with a default ofzstar
but allowinghybrid
as well? Then we could add defaults toMOM_input.yaml
that depend onMOM_vert_coord
and all it would take to switch between zstar and hybrid would be anxmlchange
call.It might turn out to be a temporary addition to
env_run.xml
(if we eventually choose to support one or the other but not both) but I think it would be really useful during this testing phase. We could even use it to support comparing different hybrid coordinates, such as the one proposed by collaborators at U-Miami.I'm happy to push changes to your branch to test it out.
I think this is a great idea. Thank you for suggesting a solution and offering to implement it.
Here are the changes needed when MOM_vert_coord = hycom1
:
NK = 75
REGRIDDING_COORDINATE_MODE = "HYCOM1"
INTERPOLATION_SCHEME = "P1M_H2"
REMAPPING_SCHEME = "PPM_H4"
BOUNDARY_EXTRAPOLATION = True
ALE_COORDINATE_CONFIG = "HYBRID:hybrid_75layer_zstar2.50m-2020-11-23.nc,sigma2,dz"
REGRID_COMPRESSIBILITY_FRACTION = 0.01
MAXIMUM_INT_DEPTH_CONFIG = "FNC1:5,8000.0,1.0,.01"
MAX_LAYER_THICKNESS_CONFIG = "FNC1:400,31000.0,0.1,.01"
COORD_CONFIG = "ALE"
Please let me know how I can help with implementing or testing this feature.
@gustavo-marques 663d769 contains the code changes I showed you -- out of the box, tx2_3v2
still has the zstar_65L
defaults, but you can run
$ ./xmlchange MOM6_VERTICAL_GRID=hycom1
to switch to hycom. We also talked about you adding hybgen
to the valid values section and then updating MOM_input.yaml
as appropriate. Lastly, I think I accounted for the tx0.25v1
grid correctly but somebody who actually runs quarter degree should probably verify that it's correct (it sounds like there might be updated tunings for the grid in the works)
Looks good to me. Has the aux_mom test suite been run, or should I run it?
aux_mom
has not been run yet; I think answers will change in all the tests. It might make sense to add a hycom
test to the test suite (just add ./xmlchange MOM6_VERTICAL_GRID=hycom1
to shell_commands
)
Update the workhorse configuration (tx2_3v2) to include geothermal heating, stochastic pertubations, and 3D KHTR. By default, KHTR (mesoscale tracer diffusion) = KHTH (GM coefficient).
These are the changes needed to replicate the latest baselines:
This pull request modifies the answers, and I have confirmed that we can compare it bit-for-bit with 2024.015 without any additional namelist changes.