-
Notifications
You must be signed in to change notification settings - Fork 0
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
GOSI10: Logarithmic bottom drag coefficient #13
Comments
@DaveStorkey and myself had a meeting and we decided to conduct a 10 years long experiment using GOSI9p8.0 forced with JRA and with the logarithmic bottom drag switched on. The run will start from the 2010 restart of the control run GOSI9p8.0 with JRA carried out by @AlexM62 (suite id = u-cn082). |
In the proximity of the Denmark Strait and Faroe channels observations suggest a bottom drag coefficient In GOSI9 with ![]() Therefore, we decided to develop the model capability to use a 2d varying Cdmin and then to set Cdmin a) GOSI9- ![]() b) GOSI9-ME ![]() |
@oceandie , how do you define/calculate the bottom roughness, |
Hi @atb299, that's a good point! The standard NEMO code allows for a constant |
I don't know why but the suite fails to write the restart of the first month when initialising from a 2010 restart from u-cn082. @ukmo-cguiavarch can replicate the error. In order to not waste too much time on this technical detail, we decided to run the full 45 years simualtion - learning the impact of this change on the full period can be actually quite useful. The suite to run this experiment is u-db949@274189 and is currently running. |
The experiment u-db949 has finished and the results are available on mass at moose:/crum/u-db949 |
Validation notes after running |
@oceandie, regarding this and the other two comparisons you've just posted (for #14 and #15), am I correct in thinking that comparison with u-cn082 is not straightforward? If the experiments all started from the u-cn082 2010 restart you can make comparisons between them, but the same period in u-cn082 has started from a very different state. |
HI @atb299, in the end all the experiments started from the same initial condition of u-cn082 and covered the same period (see #13 (comment), #14 (comment) and #15 (comment)) - so the experiments are fully comparable for the period I am analysing. |
I see. I'll look again - at first glance I thought they weren't comparable. Interesting that they all have ~2-3 Sv stronger AMOC than u-cn082. |
Here are the MARINE_VAL metrics for the following integrations (45y integrations forced by JRA and initialised from EN4):
VALNA: With logarithmic bottom drag, increase in AMOC and SPG heat content, limited impact on other metrics. VALSO: With logarithmic bottom drag, reduction in the Weddell Gyre and Ross gyre transport but small increase in ACC transport VALTRANS: With logarithmic bottom drag, significant impact on transport: improved transport in Denmark strait overflow (increase) and Faroe Bank channel overflow (reduction). Improved Bab el Mandeb outflow (increase). Degradation in Strait of Hormuz inflow (reduction). Little impact on Gibraltar outflow |
GOSI9 uses a quadratic bottom friction with a constant drag coefficient$C_D = 0.001$ . However, according to the "law-of-the-wall", in the logarithmic bottom boundary layer (BBL) $C_D$ shoud depend on the distance from the "wall" (i.e., the bottom in this case):
where$k=0.4$ is the von Karman constant, $e3t_b$ is the thickness of the deepest wet bottom cell and $z_0$ is the bottom roughness.
In NEMO, for stability reasons the log$C_D$ is bounded by Cdmin and Cdmax. For this reason, GOSI9 uses a constant $C_D$ , since with z-levels the bottom $e3t_b$ was believed to be generally to thick, resulting in a $C_D$ = Cdmin. However, the following plot shows that on the shelf and the shelf-break, the value of the log $C_D$ is larger than the costant $C_D=0.001$ used in GOSI9:
Therefore, tha aim of this issue is to test the impact of switching on the logarithmic$C_D$ in the standard GOSI9 configuration with $z^*ps$ levels.
The text was updated successfully, but these errors were encountered: