You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The averaging to generate spatially homogeneous initial conditions that is triggered in the horiz_inter_and_extrap_tracer() routines or in MOM_temp_salt_initialize_from_Z() by setting Z_INIT_HOMOGENIZE=True uses simple sums that are non-reproducing across rotation, PE-count or layout, and does not account for the possibility that some of the values come from land points. Ideally this would be modified to use properly masked and area-weighted reproducing sums, as is done in global_layer_mean(), but this would lead to answer changes at the level of roundoff.
The one known experiment where Z_INIT_HOMOGENIZE=True is used - MOM6-examples/ocean_only/single_column - is only ever run on a single PE and has just 4 columns that are (always?) ocean points, so this might not be too bad of an issue there, but it is easy to envision other cases where the current version of the code could lead to undesirable consequences.
The text was updated successfully, but these errors were encountered:
Added the ability to use reproducing sums to create spatially homogenized
tracer fields when Z_INIT_HOMOGENIZE = True, for rotational symmetry and
consistency across layouts. The previous version had used non-reproducing
sums. This new code is used when HOR_REGRID_ANSWER_DATE >= 20230101, and the
comments describing HOR_REGRID_ANSWER_DATE have been updated to reflect this. As
a part of this change, the new publicly visible routine homogenize_field was
added to the MOM_horizontal_regridding module, so that the homogenization
occurs in a single part of the code rather than being spread across several
files.
By default this commit could lead to answer changes in some cases, depending
whether and how HOR_REGRID_ANSWER_DATE is set, but it turns out that the
existing single_column test cases that use this have only 4 points and happen to
give the same answers with either the older or newer version of the code.
This commit addresses MOM6 issue mom-ocean#296 (github.com/NOAA-GFDL/issues/296),
which can be closed as soon as this commit is merged in to the dev/gfdl branch
of MOM6.
Added the ability to use reproducing sums to create spatially homogenized
tracer fields when Z_INIT_HOMOGENIZE = True, for rotational symmetry and
consistency across layouts. The previous version had used non-reproducing
sums. This new code is used when HOR_REGRID_ANSWER_DATE >= 20230101, and the
comments describing HOR_REGRID_ANSWER_DATE have been updated to reflect this. As
a part of this change, the new publicly visible routine homogenize_field was
added to the MOM_horizontal_regridding module, so that the homogenization
occurs in a single part of the code rather than being spread across several
files.
By default this commit could lead to answer changes in some cases, depending
whether and how HOR_REGRID_ANSWER_DATE is set, but it turns out that the
existing single_column test cases that use this have only 4 points and happen to
give the same answers with either the older or newer version of the code.
This commit addresses MOM6 issue #296 (github.com//issues/296),
which can be closed as soon as this commit is merged in to the dev/gfdl branch
of MOM6.
The averaging to generate spatially homogeneous initial conditions that is triggered in the
horiz_inter_and_extrap_tracer()
routines or inMOM_temp_salt_initialize_from_Z()
by settingZ_INIT_HOMOGENIZE=True
uses simple sums that are non-reproducing across rotation, PE-count or layout, and does not account for the possibility that some of the values come from land points. Ideally this would be modified to use properly masked and area-weighted reproducing sums, as is done inglobal_layer_mean()
, but this would lead to answer changes at the level of roundoff.The one known experiment where
Z_INIT_HOMOGENIZE=True
is used - MOM6-examples/ocean_only/single_column - is only ever run on a single PE and has just 4 columns that are (always?) ocean points, so this might not be too bad of an issue there, but it is easy to envision other cases where the current version of the code could lead to undesirable consequences.The text was updated successfully, but these errors were encountered: