-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for LOAR2 restart issue. #474
Conversation
Apparently the minimum value in the compute domain was 1mm. This must somehow bleed into the halos. At restart the h array was being initialized to GV%Angstrom_z. Upon changing this initial value to 0.001 (1mm) the job reproduced across restarts.
This is a good catch, Will, but I don't think that we want to introduce a specific hard-coded dimensional vertical length into the code. We should reexamine this issue and determine a more robust solution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the original code , halo points outside of the domain (j=1:4) are given a value of GV%Angstrom_z (= 1.e-10) at line 208 with a cold initialization, but this is being overwritten with zeros in MOM_temp_salt_initialize_from_Z and subsequently set to MIN_THICKNESS ( = 0.001). For warm starts at L308, thicknesses are initialized to G%Angstrom_z (in the calling routine) .
Initializing h to MIN_THICKNESS immediately prior to the call to restore_stare should therefore reproduce across restarts (need to call get_param first)
@adcroft notes that the answers should not depend on thicknesses outside of the domain, so although the solutions discussed will address the restart issue, the preferred solution is to avoid the outside dependence. We have isolated BETTER_BOUND_KH and MEKE. The former can be addressed by applying appropriate masking here: and here for MEKE, https://github.com/NOAA-GFDL/MOM6/blob/dev/master/src/parameterizations/lateral/MOM_MEKE.F90#L239 @adcroft the MOM6-examples 1 degree test case does have ocean at the first row, so it's unclear why this is not showing up in testing. |
It would appear that in my 02=01+12 test, the 12 stage was actually doing 02, so I wasn't even testing the restart. My bad. Unfortunately, using this branch (ignoring other objections), nor using the suggested masking, actually fixes the problem (for me). Using the suggested masking, even though the h's are different outside the model to the south, the interior remains the same until after the second set of stresses and fluxes, are received from the coupler because those stresses and fluxes are different. No idea how or why? I recall @wfcooke pointing out some of the fluxes are different (e.g. heat_content_lprec) right at the beginning but those don't seem to be in use because they don't lead to the immediate changes.
|
This case needs symmetric mode for MOM6/SIS2. This keeps the coupling stresses consistent across restarts. |
!
…--
Dr Alistair Adcroft (Alistair.Adcroft@noaa.gov)
Princeton University Tel: (609) 987-5073
NOAA/GFDL, 201 Forrestal Road, Princeton, NJ 08540
On Sat, Apr 22, 2017 at 5:44 PM, Matthew Harrison ***@***.***> wrote:
This case needs symmetric mode for MOM6/SIS2. This keeps the coupling
stresses consistent across restarts.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<NOAA-GFDL#474 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFlo8y5Qxv2RzNJEPYz7A7Lm4n1Nanlmks5rynSqgaJpZM4NEuiW>
.
|
- applies masking to C-grid thickness values in MOM_hor_visc which impacts answers where BETTER_BOUND_KH is enabled - applies needed masking to h points in MEKE.
Closing . We need to address this in a different manner . Thickness values from outside of the domain are impacting the solution - notably in MEKE and "better_bound" viscosities. |
* allow for assigned ice shelf thickness where hmask==3, but still solve for ice sheet velocity
Apparently the minimum value in the compute domain was 1mm. This must somehow bleed into the halos. At initialization and restart the h array was being initialized to GV%Angstrom_z. Upon changing this initial value to 0.001 (1mm) the job reproduced across restarts.