JRA55-do v1.5.0 spinup with increased vertical diffusivity

[aekiss]

We are setting up a new ACCESS-OM2-01 IAF spinup correcting the subsurface cold temperature bias by increasing the vertical diffusivity near the equator. The main purpose is to generate restart files with smaller bias for Pavel's data assimilation, but we'll use JRA55-do v1.5.0 instead of v1.4.0 so we get something else out of the run while we're at it.

Investigations of the temperature bias are documented here
COSIMA/access-om2#134
COSIMA/ACCESS-OM2-Temp-Biases#1
Andy's previous bias-correcting run from 1958-2004 with JRA55-do v1.4 is here
/home/157/amh157/payu/01deg_jra55_iaf_KvJ09
/g/data/ik11/outputs/access-om2-01/01deg_jra55v140_iaf_KvJ09/

JRA55do v1.5.0 corrects some errors in v1.4 - see COSIMA/access-om2#247

Diagnostic output will probably be minimal but we could output extra diagnostics if there's any demand for that.

[adele-morrison]

It would be great to output boundary forcing for a potential future IAF Panantarctic MOM6 run (and other regional domains? Any interest for EAC boundary forcing @ChrisC28?).

[aekiss]

oh yeah - good idea!

[aekiss]

also see https://arccss.slack.com/archives/C6PP0GU9Y/p1661474305628449
...and email chain Re: Abstracts now open for the combined Forum for Operational Oceanography (FOO) & Australian Coastal and Ocean Modelling & Observations (ACOMO) workshop

[adele-morrison]

Summary of slack / email discussions:

• @jemmajeffree wants monthly ty_trans_rho with high resolution of bins in the abyss.
• Ryan is not specifically interested in the run, but would like monthly temperature output to see how the biases change.
• @sakov needs annual restarts from the later part of the run, after spinup. How many?
• @sakov would also like daily average eta, temp, salt, u, v. Can we reduce significant figures on these?

Adding diagnostics from above comments:

• We want boundary forcing for the panAntarctic (both 37S and equator). @AndyHoggANU What variables do we need for this? temp, salt, u, v? I guess this overlaps with @sakov's request above if we save global, and then this could also be used for other regional domains apart from panAntarctic. What significant figures do we need for the boundary forcing?

There hasn't been any other interest in this run, so I would vote for not saving standard diagnostics and only saving the above list. This should cut SU costs by perhaps ~25%.

We then just need to decide what years to run and save diagnostics for. I guess @jemmajeffree wants the whole thing. How about we use 1958-1978 as spinup, where we only save monthly temp, salt, ty_trans_rho. Then save all the extra daily diagnostics for 1979-2018.

[AndyHoggANU]

I think we also need eta, right @angus-g ? Anything else we are missing there?
@adele157 - you would output this using regional outputs, I assume?

One catch is whether we want to force other domains with the IAF? Should we output BCs for EAC, Tasman, etc?

[adele-morrison]

I'm proposing to save global daily eta, temp, salt, u, v, because @sakov wants those anyway and then we can use them for any regional setup boundary forcing.

[sakov]

@sakov needs annual restarts from the later part of the run, after spinup. How many?

Ideally 48, but 24 would do almost equally well. It is more important to get the right initial conditions to address concerns in this regard.

@sakov would also like daily average eta, temp, salt, u, v. Can we reduce significant figures on these?

If space is an issue then these can be in float or compressed (and 3-daily AFAIC)

[aekiss]

@sakov I recall you saying 3-4 decimal digits in the daily outputs would be sufficient for static ensemble generation, right?

@adele157 precision reduction can be done as a post-processing step by adapting these:
https://github.com/COSIMA/01deg_jra55_iaf/blob/01deg_jra55v140_iaf_cycle4/reduce_sigfig.sh
https://github.com/COSIMA/01deg_jra55_iaf/blob/01deg_jra55v140_iaf_cycle4/qsub_loop.sh

We should decide what precision is appropriate for Pavel, regional BCs and other applications, e.g. particle tracking.

[aekiss]

The run will be in 3-month segments. The current config will save every restart (restart_freq: 1 in config.yaml) but we can prune these down to save only the 1 Jan restarts using tidy_restarts.py.

@sakov will 1 Jan be an appropriate time of year for you?

[sakov]

I recall you saying 3-4 decimal digits in the daily outputs would be sufficient for static ensemble generation, right?

yep

[sakov]

@sakov will 1 Jan be an appropriate time of year for you?

1 September seems more convenient, aiming at the upcoming Antarctic season. This if the new ensemble will make a difference and we decide to replace the current Demonstrator run with the new one. (Optimistic scenario.) Otherwhile it does not matter. September/March can also be better time of the year to start the ice model, near the yearly maximum/minimum, while 1 January is in a middle of the melting/freezing season...

[aekiss]

With 3mo runs you'll have a choice between 1 Jan, 1 Apr, 1 Jul or 1 Oct - which of those would be preferable?

[jemmajeffree]

Is there a reason why we can't start stagger the start so our 3 month starts hit 1 Sep? Ie run a 2 month segment and then 3 month segments or start from 1 Mar and ignore the first two months of forcing?

[aekiss]

Yeah I guess we could do that but it would make it a bit messy having output files that straddle 2 years

[aekiss]

More finely resolved density binning for abyssal waters has also been suggested.

However, at present the bin size is uniform so we can't improve resolution in the deep ocean without getting way too much data in shallower depths. It would be better to have adjustable bin sizes.

It looks like @rmholmes made a start on this here mom-ocean/MOM5@43dae7d
and there might be other relevant things in the branches in his MOM5 fork https://github.com/rmholmes/MOM5/branches/stale

[sakov]

With 3mo runs you'll have a choice between 1 Jan, 1 Apr, 1 Jul or 1 Oct - which of those would be preferable?

1 October, I guess

[adele-morrison]

I think for the overturning we should just choose the upper bin to be a very dense value, and not bother saving the upper ocean data. Can anyone see a problem with that?

@jemmajeffree, if we go this route, can you advise on upper and lower bins limits and how many levels would suit your purposes?

[AndyHoggANU]

Oh, that's a good idea @adele157 -- not sure what Jemma thinks but I would advocate going to about 1035.5 so that you get most of the AMOC as well as all of the abyssal cell.

[jemmajeffree]

I only need 1036.5 to 1037.5 unless we care about AABW in the Tasman Sea. We could also grab the AMOC as well, but it seems fairly well resolved in other runs so not sure how much value that adds. I'm looking into how many levels I want in this range today.

Previous cycle 3 overturning in the Atlantic, noting that it captures the AMOC relatively smoothly but only has AABW in one bin:

[AndyHoggANU]

So, if we kept 75 diagnostic levels but reduced the range to be (1035,1037.5) then d\rho would reduce from ~0.13 to ~0.033. Is that sufficient? Or do we need finer?

[jemmajeffree]

That should be fine enough; I'm just checking now what happens when you use that resolution

[bkgf]

For downscaling for region models do you plan on also outputting daily surface fluxes (t,s,stresses) as well as u,v,t,s,eta?

[adele-morrison]

@bkgf we've been forcing MOM6 regional models with JRA55-do, so hadn't thought about saving surface fluxes. What do you force your regional models with? We could definitely consider this if it would be of use.

Also is it worth thinking about saving sea ice fluxes if we want to do smaller regional Antarctic domains? We can't do sea ice boundary conditions with SIS2, but once we couple with CICE6 we may be able to. Anyone know what's needed for sea ice boundary forcing? Would it be much extra to save? Or is that too far off in the future it's not worth planning for yet?

[AndyHoggANU]

Fluxes are useful for some experiments, but if you have a sea ice model I think forcing with the atmospheric state is a better solution.

[AndyHoggANU]

For saving data, I think we should add minimal monthly data. For 3D fields this could be:

        age_global:
        dzt:  
        pot_rho_2:
        salt:
        temp:
        tx_trans:
        ty_trans_nrho_submeso:
        ty_trans_rho:
        ty_trans_submeso:
        ty_trans:
        u:
        v:

which is a subset of what is default. I wouldn't do any squared fields for this run, but I would save most of the standard monthly 2D fields. That would be about it ...

[bkgf]

We also run experiments with surface fluxes only - to reduce complexity - and to tune the fluxes to get the spatial extent of polynyas closer to reality - something sea ice models still can't do. Im interested to move our boundary condition data to be something the Australian community can provide, and to start thinking about how future climate experiments can be consistently downscaled. At the moment we use reanalysis products including ERA-Interim, ECCO, and sea ice production from satellite measurments.

[adele-morrison]

Ben, which variables do you need for the fluxes? And at what temporal resolution? I guess if these are only 2D they may not be too expensive.

…

On Thu, 1 Sept 2022 at 15:20, Ben Galton-Fenzi ***@***.***> wrote: We also run experiments with surface fluxes only - to reduce complexity - and to tune the fluxes to get the spatial extent of polynyas closer to reality - something sea ice models still can't do. ________________________________ From: Andy Hogg ***@***.***> Sent: 01 September 2022 14:56 To: COSIMA/01deg_jra55_iaf ***@***.***> Cc: Ben Galton-Fenzi ***@***.***>; Mention ***@***.***> Subject: Re: [COSIMA/01deg_jra55_iaf] JRA55-do v1.5.0 spinup with increased vertical diffusivity (Issue #14) Fluxes are useful for some experiments, but if you have a sea ice model I think forcing with the atmospheric state is a better solution. — Reply to this email directly, view it on GitHub< #14 (comment)>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ABHFVHCW6RGOOAXGJ7AFN6DV4AZRHANCNFSM57OBZU3Q >. You are receiving this because you were mentioned.Message ID: ***@***.***> This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise. — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACA44U6OCZN7DRNXLVHRCL3V4A4ITANCNFSM57OBZU3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[aekiss]

Just noting that the diffusivity settings from @AndyHoggANU's run /home/157/amh157/payu/01deg_jra55_iaf_KvJ09

    j09_bgmax         = 5e-06
    j09_bgmin         = 1e-05
    j09_diffusivity   = .true.
    j09_lat           = 30.0

are not actually what we'd intended to use - see COSIMA/ACCESS-OM2-Temp-Biases#1 (comment).

Do we still want to use these settings?

[aekiss]

@jemmajeffree FYI 01deg_jra55v140_iaf_cycle4 used 160 density steps from 1028-1038, which might be a small improvement for you https://github.com/COSIMA/01deg_jra55_iaf/blob/01deg_jra55v140_iaf_cycle4/ocean/input.nml#L151

[aekiss]

diff_cbt_t should also be saved monthly so we can compare vertical temperature diffusivity with the previous runs.

[adele-morrison]

I'm having second thoughts about what year to start the daily output (for @sakov and for forcing regional models). I had planned to start saving it in 1979. But for regional models forced by the IAF, we'll need a spinup period as well right? Maybe 10 years of spinup? So do we want 1970-1979 for spinup, then 1980-2018 for analysis? Or is that too much data to save?

[adele-morrison]

A quick check of the biases in this new run:
This is an average over years 1969-1973 (old run is top left, new run is top right, difference between them at the bottom):

That red blob just north of the equator looks to be getting worse.
@sakov

[adele-morrison]

This run is now complete. Data is here:
/g/data/ik11/outputs/access-om2-01/01deg_jra55v150_iaf_cycle1/

@bkgf @sakov