-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conservative or potential temperature #24
Comments
That's awkward. I'm not sure how to choose between these - @russfiedler can you offer any suggestions? In ACCESS-OM2 we use Here's an overview of what these options mean.
|
Looks like we'll also need to be careful in choosing the right freezing point option. |
Thanks Andrew. We're currently using WRIGHT, the same as OM4. I don't think I fully understand the issues here. Anyone know why GFDL is not using TEOS-10? Is it due to the slow down (do we know how much slower)? Or is it because "there remain unanswered research questions raised by IOC et al. (2010), in particular regarding the treatment of salinity." (Griffies et al. 2016, Appendix D). Is it worth doing a test (in panan-01 perhaps?) with both to check the slow down? |
Yes, a short test of NEMO vs WRIGHT could be worthwhile. The run wouldn't need to be long. |
Actually I'm not sure whether NEMO would be faster than TEOS-10, since GSW apparently uses Roquet et al 2015 |
So maybe test NEMO, WRIGHT and TEOS-10? |
Ok, so a test of TEOS-10 vs WRIGHT? @fabiobdias would you be up for doing those tests with your panan-01 config (with old boundary forcing)? Perhaps a year of each. Mostly we want to know timing. Just to confirm, can someone check that these are the 2 runs we want:
|
Posted that before I saw your last message Andrew. So add a 3rd run to the above two:
|
Yes, I definitely can perform those runs. Is it the point to know about the run efficiency? (meaning that I just neglect the conversion between potential temperature/practical salinity to conservative temp/absolute salinity for tests 2 and 3?) |
Yes I think that's right @fabiobdias - we're only interested in comparing run times for these tests, so just leave the initial conditions and boundary forcing the same for all. We can ping Griffies after we do that and find out more about the GFDL's reasoning for sticking with WRIGHT, whether it is a choice based on speed or something to do with the salinity issues of TEOS-10. |
Quick update on these test runs. The test 1 with EOS_WRIGHT and TFREEZE_LINEAR is running well into the first 3 months, but the two others (test 2 - EOS_NEMO and 3 - EOS_TEOS10, both with TFREEZE_TEOS10) crashed during the initialisation with some segmentation fault error. I couldn't identify any clear error from the log files, but if anyone wants to have a look, here is where they sit:
|
I think it might be crashing because the underlying name for the temperature tracer is either |
So is that fixable? |
Yes, I can write something to deal with both forms of the tracers. However, I don't think the OBC code will do any conversion between the two, so the forcing for the conservative temp runs may need to be offset? |
I think for now we don't care if the model is doing the right thing (i.e.
all temperature inputs match the prognostic variable). We just want to know
about timing, so as long as we can get the model to run we're good for now,
even if we wouldn't trust the outputs.
…On Thu, 23 Feb 2023 at 15:29, Angus Gibson ***@***.***> wrote:
Yes, I can write something to deal with both forms of the tracers.
However, I don't think the OBC code will do any conversion between the two,
so the forcing for the conservative temp runs may need to be offset?
—
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACA44U7ZXEKJNTKWQII5UPDWY3RRTANCNFSM6AAAAAAVBJSYLM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
@fabiobdias try |
Results from the quick tests (3-month run): Test 1 (EOS_WRIGHT, TFREEZE_LINEAR, potential temp) = ~3h20min So given that WRIGHT is just slightly more efficient than the other two, it would be good to understand why this was the GFDL choice... |
@StephenGriffies, we are trying to decide what EOS to use for our new MOM6 simulations (panAntarctic regional currently, but soon global ACCESS-OM3 also). Would you please be able to give us a brief rundown of the GFDL choice to use WRIGHT in OM4? Is this simply due to runtime efficiency? Or is it due to issues related to the calculation of absolute salinity? Also, will you still be using WRIGHT going forward, or are there plans to switch to TEOS-10 at some point? |
This is a timely query as Hallberg has been diving into details of the EOS. Is it possible for you to post this query to the MOM6 github repo so that Bob can answer directly, and spread his wisdom to the broader MOM6 community? In summary, we are planning to move to TEOS10 with MOM6, and Bob should be updating some code soon to address certain issues with the present implementation (and with a bug in one of the coefficients in the Fortran TEOS10 code). The reason we have not moved earlier is based on intellectual inertia and the perceived lack of major payoff for the move. Even so, we are mindful that TEOS10 is a 21st century invention that should be used in MOM6. |
Thanks @StephenGriffies! I've posted on the MOM6 github discussions here, so we can track any more info linked to this question. (Also, was that the right location to post? It didn't quite seem to fit as an issue and I couldn't see anywhere else to ask.) |
Yes, I think that is a good place to post the issue, since it concerns a topic in MOM6 development rather than MOM6 experiments. Thanks @adele157 |
Coming through the pipeline (among some other significant changes) are corrections to existing EOS implementations, and a few new ones too: NOAA-GFDL/MOM6#331 |
Ah great - so I guess we should switch to |
Currently we're sticking with |
Just noting that the relevant PR has been merged, so |
Our MOM6 panan config is currently using potential temperature and practical salinity (
USE_CONTEMP_ABSSAL = False
) andEQN_OF_STATE = "WRIGHT"
.With
USE_CONTEMP_ABSSAL = True
, we would have both conservative temperature and absolute salinity, but I don't think there is an option to choose these separately. There is also a note with this that "Care should be taken to convert them to potential temperature and practical salinity before exchanging them with the coupler and/or reporting T&S diagnostics." I am guessing this conversion will already be done for us if we are using MOM6-SIS2? Can anyone confirm that?Equation of state options are "LINEAR", "UNESCO", "WRIGHT", "NEMO" and "TEOS10". There is no pre-TEOS10 option.
It seems like no matter which of these options we choose, we are going to have to convert something (either the temp or salinity) from our ACCESS-OM2-01 initial conditions.
Opinions on which of these options we want?
The text was updated successfully, but these errors were encountered: