Skip to content
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

Closed
adele-morrison opened this issue Feb 20, 2023 · 25 comments
Closed

Conservative or potential temperature #24

adele-morrison opened this issue Feb 20, 2023 · 25 comments

Comments

@adele-morrison
Copy link
Contributor

Our MOM6 panan config is currently using potential temperature and practical salinity (USE_CONTEMP_ABSSAL = False) and EQN_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?

@aekiss
Copy link

aekiss commented Feb 20, 2023

That's awkward. I'm not sure how to choose between these - @russfiedler can you offer any suggestions?

In ACCESS-OM2 we use eos_preteos10=true which is Jackett et al. 2006. Here's our discussions on pre-TEOS-10 vs. TEOS-10, and the difference between potential and conservative temperature.

Here's an overview of what these options mean.

@aekiss
Copy link

aekiss commented Feb 20, 2023

Looks like we'll also need to be careful in choosing the right freezing point option.

@adele-morrison
Copy link
Contributor Author

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?

@aekiss
Copy link

aekiss commented Feb 21, 2023

Yes, a short test of NEMO vs WRIGHT could be worthwhile. The run wouldn't need to be long.

@aekiss
Copy link

aekiss commented Feb 21, 2023

Actually I'm not sure whether NEMO would be faster than TEOS-10, since GSW apparently uses Roquet et al 2015

@aekiss
Copy link

aekiss commented Feb 21, 2023

So maybe test NEMO, WRIGHT and TEOS-10?

@adele-morrison
Copy link
Contributor Author

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:

  1. Exactly the setup you have now, with EQN_OF_STATE = "WRIGHT", USE_CONTEMP_ABSSAL = False, TFREEZE_FORM = "LINEAR".
  2. Set the following in MOM_input: EQN_OF_STATE = "NEMO", USE_CONTEMP_ABSSAL = True, TFREEZE_FORM = "TEOS10".

@adele-morrison
Copy link
Contributor Author

Posted that before I saw your last message Andrew. So add a 3rd run to the above two:

  1. Set the following in MOM_input: EQN_OF_STATE = "TEOS10", USE_CONTEMP_ABSSAL = True, TFREEZE_FORM = "TEOS10".

@fabiobdias
Copy link

fabiobdias commented Feb 21, 2023

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?)

@adele-morrison
Copy link
Contributor Author

adele-morrison commented Feb 21, 2023

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.

@fabiobdias
Copy link

fabiobdias commented Feb 23, 2023

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:

/scratch/v45/fbd581/mom6-panan-test3_EOS (running)
/scratch/v45/fbd581/mom6-panan-test2_EOS (crashed)
/scratch/v45/fbd581/mom6-panan-test3_EOS (crashed)

@angus-g
Copy link
Collaborator

angus-g commented Feb 23, 2023

I think it might be crashing because the underlying name for the temperature tracer is either temp (for potential) or contemp (for conservative): https://github.com/mom-ocean/MOM6/blob/71e110430941e33708a3f6f64e06873a28923967/src/core/MOM.F90#L2468-L2476. However, the OBC code always assumes it's called temp (and same issue for salinity, I guess): https://github.com/mom-ocean/MOM6/blob/71e110430941e33708a3f6f64e06873a28923967/src/core/MOM_open_boundary.F90#L4651-L4654

@adele-morrison
Copy link
Contributor Author

So is that fixable?

@angus-g
Copy link
Collaborator

angus-g commented Feb 23, 2023

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?

@adele-morrison
Copy link
Contributor Author

adele-morrison commented Feb 23, 2023 via email

@angus-g
Copy link
Collaborator

angus-g commented Feb 23, 2023

@fabiobdias try /scratch/v45/ahg157/exes/MOM6-OBC-contemp, which has that tracer behaviour patched. Preferably on all three cases, because it's based on slightly newer code.

@fabiobdias
Copy link

Results from the quick tests (3-month run):

Test 1 (EOS_WRIGHT, TFREEZE_LINEAR, potential temp) = ~3h20min
Test 2 (EOS_NEMO, TFREEZE_TEOS10, conservative temp) = ~3h37min
Test 3 (EOS_TEOS10, TFREEZE_TEOS10, conservative temp) = ~3h53min

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...

@adele-morrison
Copy link
Contributor Author

@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?

@StephenGriffies
Copy link

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.

@adele-morrison
Copy link
Contributor Author

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.)

@StephenGriffies
Copy link

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

@angus-g
Copy link
Collaborator

angus-g commented Mar 13, 2023

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

@aekiss
Copy link

aekiss commented Mar 15, 2023

Ah great - so I guess we should switch to ROQUET_RHO (the EOS formerly known as NEMO) when this PR is merged? Might need to also consider how the boundary forcing was calculated (e.g. JACKETT06 would suit ACCESS-OM2 data if we decide to use that after all).

@adele-morrison
Copy link
Contributor Author

Currently we're sticking with WRIGHT and using potential temperature. But let's remember this discussion for ACCESS-OM3 development and try ROQUET_RHO there.

@aekiss
Copy link

aekiss commented Apr 25, 2023

Just noting that the relevant PR has been merged, so ROQUET_RHO is now available: NOAA-GFDL/MOM6#331

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants