Check basal melt code / runoff diagnostics #1
Comments
|
Maybe mean salinity integrated over the shelf? It will diverge, but it should take time for that divergence -- and should be a predictable. Also, mean surface salinity on the shelf should be larger, immediately. These are qualitative, more than quantitative [edited], checks... |
|
How about some theta-S diagrams as well. I'm still interested to see these. |
|
Some zoomed in overturning circulation plots over the shelf, to see how the MW at depth is triggering an inverse circulation response there cf control. |
|
Lots of good ideas here, I suggest we split some of these off into separate issues, so it doesn't get too cluttered here. We can always refer back to those in the discussion here if needed. |
|
What is the final choice that was made on the melt code? |
|
Thanks Adele!
|
adele-morrison
changed the title
|
The total runoff in the perturbation (from the Need to look at the code, check what that new diagnostic is saving and what runoff is being added in.
Also there is a weird temporal variation in that ~2% value that resets on restarts and then trends downward. But at a later period is different again:
|
|
I looked into this a little more and turns out the plot above is the sum of So I think our first step here should be to check in the code what the |
|
Yep, this may explain the unexpected result of the overturning decreasing when we were expecting it to increase. Probably worth holding off on any other analysis until we get to the bottom of this I reckon. |
|
Yes agreed. Thanks for digging into the data and uncovering. |
|
I deleted my previous comment, please disregard it. A few months ago, I did a few changes in the initialization of the code and then continued the run since February 2153, most likely there was a bug that I was not aware of. The strange and large values are no longer present in the output after February 1953. See below The 2% issue is still there, but it is a constant value in time (0.02207607). I'm wondering if the first or the last level in the iteration is not being taken into account... |
|
I just did a print to check this and the iteration seems to work fine, I'll keep digging. Some details below |
|
Naive question, but where are the basal melt values coming from? Are you taking them from the control runoff or from the data in /home/552/pc5520/forcing_files/basal_fw.nc ? |
|
The code has both options for import, for this particular case the data is set in ocean_sbc.F90, all runoff values to the south of -60 (line 3615) |
|
I just exported the 2d basal (fwfisf variable in the MOM code, fw flux that is distributed at depth), it is in /g/data/e14/pc5520/access-om2/archive/01deg_jra55v13_ryf9091_rerun_for_easterlies/accessom2-GPC003/output1034/ocean/rregionocean_monthly_2d_basal.nc (basal_fwflx2d) |
|
Good news, 2% problem solved. The issue was coming from the input data of max and min depth. There was a specific region where the max depth was smaller than the min depth, and therefore the iteration was not properly done. I fixed this and now the ratio between the basal melt and the runoff is 1. |
|
Nice one Pedro! Yes, I reckon start from scratch and run another 5 years. Maybe start the other 2 perturbations from scratch too and do 2 years each of them also. Are you happy for this to run on e14 hours @matthew-england-unsw ? |
|
Yes absolutely thanks Adele. |
|
Great sleuthing Pedro! |
|
A real model developer in the making. Congrats
On Sat, Jul 30, 2022 at 04:05 Andrew Kiss ***@***.***> wrote:
Great sleuthing Pedro!
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQFVG63F6EG47DAAZ2IELDVWSEYFANCNFSM536RMMTA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
--
I appreciate that many folks, like me, read/respond to emails only at
selected times.
Dr. Stephen M. Griffies (he/him)
NOAA Geophysical Fluid Dynamics Lab
Princeton University Atmospheric & Oceanic Sciences
Princeton, USA
https://stephengriffies.github.io/
|
|
Thanks a lot everyone! Is great to see all this comments. Sounds good, I'll run a few months, and if everything is fine, I'll go for the whole 5 years. |
|
What do we think about only putting the basal melt (not calving) at depth if Pedro is starting from scratch again? That way it would be more comparable to a possible later run with icebergs spread laterally at the surface. If we go this route, what’s the path to the forcing (v1.4?) that has the calving / basal split @aekiss ? Also would be good to check that the total runoff in this new version is identical to the v1.3 control. |
|
I think it is a good idea just to add calving at surface if that is how it is done typically.
…________________________________
From: Adele Morrison ***@***.***>
Sent: 01 August 2022 15:53
To: pedrocol/basal_mom5-collaborative-project ***@***.***>
Cc: Ben Galton-Fenzi ***@***.***>; Comment ***@***.***>
Subject: Re: [pedrocol/basal_mom5-collaborative-project] Check basal melt code / runoff diagnostics (Issue #1)
What do we think about only putting the basal melt (not calving) at depth if Pedro is starting from scratch again?
That way it would be more comparable to a possible later run with icebergs spread laterally at the surface. If we go this route, what’s the path to the forcing (v1.4?) that has the calving / basal split @aekiss<https://github.com/aekiss> ? Also would be good to check that the total runoff in this new version is identical to the v1.3 control.
—
Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABHFVHFDHSA7A4LQFOL2B4LVW5Q4XANCNFSM536RMMTA>.
You are receiving this because you commented.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.
|
|
Good point Adele, I agree that's a more logical next step when the final step is basal at depth, and icebergs distributed.
|
|
The infrastructure is there, but we've never tried forcing MOM with separate liquid and solid runoff. Not sure what unforeseen issues we'd encounter. Both v1.4 and v1.5 of JRA55-do have separate liquid and solid runoff; these are combined into one liquid field for earlier versions. Currently all configurations have used one of these two arrangements:
For v1.4 and v1.5, liquid and solid runoff are provided separately to CICE, which then combines them into a single field of liquid runoff before passing to MOM. So what MOM sees is effectively the same as what was done with v1.3. There are solid runoff and heat fields passed through the coupler, but they're currently unused. More details here: COSIMA/access-om2#155 If we're thinking of going to v1.4.0, we could consider the latest 1.5.0 which fixes a few errors in v1.4.0, and has an extension (v1.5.0.1) that's continuously updated to nearly the present day: COSIMA/access-om2#247 Data locations are: All current configurations of ACCESS-OM2 use v1.4.0, e.g. https://github.com/COSIMA/01deg_jra55_ryf/tree/master ; Differences between JRA55-do versions are documented in section C here. |
|
I was thinking just to use the liquid / solid runoff from v1.4, but keep the rest of the forcing from v1.3 so the control doesn’t have to be rerun. |
|
As far as I can see from the documentation, runoff from Canadian and Greenland glaciers is the only difference between v1.3 and v1.4, so the spinup might not be very different. On the other hand, v1.3 does supply the Depoorter (2013) calving flux |
|
That sounds like a good approach to stick with v1.3 Andrew and just
subtract licalvf from runoff in the Southern Hemisphere. Pedro, is your
code easy to modify to apply partial runoff at the surface and at depth?
…On Tue, 2 Aug 2022 at 08:45, Andrew Kiss ***@***.***> wrote:
As far as I can see from the documentation
<https://climate.mri-jma.go.jp/pub/ocean/JRA55-do/docs/v1_5-manual/User_manual_jra55_do_v1_5.pdf>,
runoff from Canadian and Greenland glaciers is the only difference between
v1.3 and v1.4, so the spinup might not be very different.
On the other hand, v1.3 does supply the Depoorter (2013) calving flux
licalvf around Antarctica in
/g/data/qv56/replicas/input4MIPs/CMIP6/OMIP/MRI/MRI-JRA55-do-1-3/landIce/yrC/licalvf/gn/v20180412/licalvf_input4MIPs_atmosphericState_OMIP_MRI-JRA55-do-1-3_gn_2007-2008-clim.nc,
so we could stick with v1.3 and use this for solid runoff, so long as we
also subtract it from the combined liquid+solid runoff friver. Note that
in the NH the runoff friver would still be liquid+solid, since licalvf is
zero there.
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACA44UYXK7SMQZ7C4UN6CTDVXBHPJANCNFSM536RMMTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
@aekiss If I'm not wrong the calving field is not used (calving is zero everywhere) and all the fresh water flux is present in the runoff variable. If this is the case we would need to import that licalvf variable from the file you mention. |
|
I went for a very pragmatic option, I took the runoff box and put the calving inside: Except, I'm getting another error: assertion failed: accessom2_sync_config incompatible config between atm and ice: num_atm_to_ice_fields |
|
This JRA55-do v1.3-based config needs to be updated to what was done for the v1.4 configs so it couples I think you'll only need to fix these files You can use these changes as a guide COSIMA/01deg_jra55_ryf@v1.3.1...v1.4.0 - just make the changes that involve |
|
Also, I was hoping to use git to see the changes you're making, but I get - what happens when you do |
I modified atmosphere/forcing.json, but the current version of the code does not have a fields_from_atm variable, it looks it is hard coded: cice5/build_auscom_3600x2700_722p/cpl_interface.f90 |
|
|
|
Looks like you're using code from late 2019 Is this what you've based your MOM edits on? I'm in the middle of updating libaccessom2, cice and the standard configs and executables, so there should be newer versions available sometime next week which would be a better place to start from. |
|
I have forgotten if this is added as a freshwater volume flux, or a salt flux? Would you please remind me?
…________________________________
From: Andrew Kiss ***@***.***>
Sent: 05 August 2022 10:04
To: pedrocol/basal_mom5-collaborative-project ***@***.***>
Cc: Ben Galton-Fenzi ***@***.***>; Comment ***@***.***>
Subject: Re: [pedrocol/basal_mom5-collaborative-project] Check basal melt code / runoff diagnostics (Issue #1)
Looks like you're using code from late 2019
https://github.com/COSIMA/access-om2/tree/7f834a0<https://github.com/COSIMA/access-om2/tree/7f834a0>
So it's missing the updates needed for JRA55do v1.4.
Is this what you've based your MOM edits on?
I'm in the middle of updating libaccessom2, cice and the standard configs and executables, so there should be newer versions available sometime next week which would be a better place to start from.
—
Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABHFVHHP7XOUJR526IQC3FDVXRLAZANCNFSM536RMMTA>.
You are receiving this because you commented.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.
|
|
Yes, I'm using the same code that Adele used for her run /home/157/akm157/access-om2/source_code/ (for comparison ends, and because I was not able to use the restarts in the newest version of the code). The Basal melt parameterization is coded in the latest version of the code, and I adapted this for the late 2019 version of the code. |
|
@bkgf The basal melt is added in the same way as the runoff is, as temperature and salinity fluxes, and in a separate routine as a mass/volume flux (exactly as runoff) |
|
Hm, ok. This idea of splitting basal and calving fluxes is starting to feel like a rabbit-hole... It looks like you'd need new branches of the code (cice, and possibly libaccessom2 and mom) based on your old versions but with cherry-picked bits from newer code, which seems error-prone and kludgey. It would be cleaner and easier to do the split based on the established v1.4 (or 1.5) configs and code, where these problems have already been resolved. It could then be adapted to use this hybrid v1.3 + licalvf if desired. What error do you get when you try running the new code with your old restarts? |
|
I agree, it looks very complicated. Probably the easiest will be to make an offline interpolation of the calving field in the MOM grid, and import this in ocean_sbc.F90. But this is only a workaround, it won't be useful for newer runs. This was several months ago (February), I lost track of the errors, I only got this (see below) from a mail. If I remember well and I'm not wrong, I think the newer version of the code uses more tracers (co2? maybe) than the previous version, and the restarts don't have these fields. forrtl: error (78): process killed (SIGTERM) |
|
That does sound like it's getting complicated. Given that there are so many assumptions already with this method of putting the basal melt at depth, how about we just go with something simple, like putting 50% of the runoff at depth and leaving the other 50% at the surface. The 50% is an approximation of the net circumpolar fluxes from Depoorter et al. 2013 (52% basal melt, 48% calving, but these have ~4% uncertainties). |
|
There are now 2 types of ACCESS-OM2 MOM executables, one including BGC ( |
|
@aekiss I will open this in a new issue, since we have to make the import of the calving field work and we also have to make the restarts work in the new version of the code. These two aspects may be out of the scope of the validation of the basal melt parameterization |
|
Agreed @adele157 that does sound like a sensible starting point. |
|
Yes @adele157 that sounds a lot easier - it amounts to having a nonuniform injection of runoff with depth. Perhaps the split fraction could be a namelist parameter? |
|
Thanks @pedrocol - maybe 2 new issues would be even better, as calving import and restarts are independent problems |
|
Great, I'll put this to run, we may have a couple of years for the next meetings. |
|
A constant split is a good place to start, but pretty rough - Depoorter et al fig 1 show the ratio depends strongly on location. |
|
Probably a bit late to say this, but something other than a 50/50 split (say, 55/45) would be better for testing, as it will show you if you've accidentally swapped variables anywhere. |
|
Here is the piece of code that performs the distribution at depth and applies this to the tendency. If the amount of runoff present in the basal3d variable is ok, as we have seen in the validation plots, normally the code should behave correctly. As an additional check I put below a mass budget of the basal melt param run: and for the control run
If we add the calving, basal and river, of the basal melt param run, and compare this with the control run, the numbers are almost the same (precision question aside). |
|
These are encouraging...single time step diagnostics appear fine for mass. Here are further diagnostics that we should document: --single time step diagnostics for heat. We should be sure the heat content impacts from basal melt are properly accounted for. --single time step diagnostics for salt. Although there is no salt in the basal melt, I still wish to see the salt diagnostics to be sure everything is fine. --multiple time step diagnostics for heat and mass and salt. The multiple time step diagnostics sometimes pick up mistakes that are missed by the single time step diagnostics. The model has a default for the number of time steps it integrates over; I think it is 100. Just need to be sure the number of time steps is not more than the length of the run. |
|
Thanks for your comment Steve. In order to be able to compare those variables I have to run the code in the same way as the control run, this is, distributing the basal in the first 40 meters and using the same temperature for the runoff (tbasal=trunoff), right? |
|
I am not looking for exactly reproducing an earlier run. Just wish to look at order of magnitudes for the diagnostics that check for conservation. If the orders are roughly the same, then we are fine. So any run should be sufficient. |
|
And the min/max depth values come from basal_fw.nc? What happens if there
is a mismatch in lat/lon between the runoff and the min/max depth values?
…On Fri, 29 Jul 2022 at 15:29, Pedro ***@***.***> wrote:
The code has both options for import, for this particular case the data is
set in ocean_sbc.F90, all runoff values to the south of -60 (line 3615)
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACA44U6JNCPFBSN2PAK3X2DVWNT33ANCNFSM536RMMTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
In that case, I set two standard values to distribute the runoff at depth, 200m (mindepth, typical value of shelf front) and 400m (maxdepth, 200m (400-200) to distribute the runoff looked ok to me, but we can discuss this value). The runoff data comes from a different source than the min/max depths data.
________________________________
From: Adele Morrison ***@***.***>
Sent: Tuesday, 11 October 2022 17:55
To: pedrocol/basal_mom5-collaborative-project ***@***.***>
Cc: Pedro ***@***.***>; Mention ***@***.***>
Subject: Re: [pedrocol/basal_mom5-collaborative-project] Check basal melt code / runoff diagnostics (Issue #1)
And the min/max depth values come from basal_fw.nc? What happens if there
is a mismatch in lat/lon between the runoff and the min/max depth values?
On Fri, 29 Jul 2022 at 15:29, Pedro ***@***.***> wrote:
The code has both options for import, for this particular case the data is
set in ocean_sbc.F90, all runoff values to the south of -60 (line 3615)
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACA44U6JNCPFBSN2PAK3X2DVWNT33ANCNFSM536RMMTA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
—
Reply to this email directly, view it on GitHub<#1 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFRU4R2G4J4Y6GXJLGG4LILWCUFMVANCNFSM536RMMTA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Are there any simple tests / plots we can do to show the code is working as expected?
e.g. Plot depth integrated runoff from output in Control and Perturbation to check they're the same.
Plot the zonally integrated runoff as a function of depth that it enters the model (is there a new diagnostic available that has this information?)
Other sanity checks to show that nothing unexpected has been changed (apart from runoff and heat flux associated with runoff)?
Other ideas?
The text was updated successfully, but these errors were encountered: