JRA55-do v1.5.0 spinup with increased vertical diffusivity

aekiss commented 2 years ago

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 https://github.com/COSIMA/access-om2/issues/134 https://github.com/COSIMA/ACCESS-OM2-Temp-Biases/issues/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 https://github.com/COSIMA/access-om2/issues/247

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

adele-morrison commented 2 years ago

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 commented 2 years ago

oh yeah - good idea!

aekiss commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

yep

sakov commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

aekiss commented 2 years ago

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 https://github.com/mom-ocean/MOM5/commit/43dae7dc0a4d9bf22ba5578c3eae3e65cd84d6dc and there might be other relevant things in the branches in his MOM5 fork https://github.com/rmholmes/MOM5/branches/stale

sakov commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

bkgf commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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< https://github.com/COSIMA/01deg_jra55_iaf/issues/14#issuecomment-1233739992>, 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 https://github.com/COSIMA/01deg_jra55_iaf/issues/14#issuecomment-1233754176, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACA44U6OCZN7DRNXLVHRCL3V4A4ITANCNFSM57OBZU3Q . You are receiving this because you were mentioned.Message ID: @.***>

aekiss commented 2 years ago

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 https://github.com/COSIMA/ACCESS-OM2-Temp-Biases/issues/1#issuecomment-1237687193.

Do we still want to use these settings?

aekiss commented 2 years ago

@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 commented 2 years ago

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

adele-morrison commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

@bkgf @sakov

COSIMA / 01deg_jra55_iaf

JRA55-do v1.5.0 spinup with increased vertical diffusivity #14