Conservative or potential temperature

[adele-morrison]

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]

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.

• LINEAR - not suitable
• UNESCO is the fit to the UNESCO equation of state given by Jackett & McDougall (1995)
• WRIGHT is Wright (1997) and claims to be computationally efficient
• ~NEMO~ ROQUET_RHO is the Roquet el al 2015 expressions for TEOS-10, which sounds like it would be more computationally efficient than the "TEOS10" option. It appears to require absolute salinity. Not sure if that means 2 salinity tracers.
• TEOS-10 calls the Gibbs SeaWater (GSW) Oceanographic Toolbox of TEOS-10 as of 2016.

[aekiss]

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

[adele-morrison]

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]

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

[aekiss]

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

[aekiss]

So maybe test NEMO, WRIGHT and TEOS-10?

[adele-morrison]

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]

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

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

[fabiobdias]

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]

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]

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]

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]

So is that fixable?

[angus-g]

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]

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 https://github.com/COSIMA/mom6-panan/issues/24#issuecomment-1441203715, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACA44U7ZXEKJNTKWQII5UPDWY3RRTANCNFSM6AAAAAAVBJSYLM . You are receiving this because you authored the thread.Message ID: @.***>

[angus-g]

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

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]

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

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]

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]

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]

Coming through the pipeline (among some other significant changes) are corrections to existing EOS implementations, and a few new ones too: https://github.com/NOAA-GFDL/MOM6/pull/331

[aekiss]

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]

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]

Just noting that the relevant PR has been merged, so ROQUET_RHO is now available: https://github.com/NOAA-GFDL/MOM6/pull/331