I’m combining the JRA55-do runoff with a calving flux at the Antarctic margins (already on ACCESS-OM2-01 grid) into a single forcing file. My goal is to regrid the JRA55-do (720x1440) onto the OM2-01 grid (2700x3600), then merge with the calving flux. Just want to see if anyone has done this conservative remapping before and have any tips to share.
Will you use the new forcing file in ACCESS-OM2? If so, my understanding is OM2 handles it online / in the model to ensure the runoff doesn’t end up in land cells.
yes the idea it to force back ACCESS-OM2 with those fluxes. This run is part of the basal melting project where we prescribed the meltwater at depth in ACCESS-OM2-01 (that I presented in the last NRI workshop).
In this setup, the calving fluxes are hard-wired in MOM5, and internally it’s ensured it goes at surface (upper-40m to be exact), whereas the JRA55-do runoff is inserted at the depths of the ice shelves.
In the experiment I’m setting up, I want to source the JRA55-do runoff + Merino calving flux at the surface–so that’s why I need to combine both into a single file. I want only a Meltwater anomaly to be spread at depth is (which replaced the JRA55-do runoff in the original control setup).
So I’m guessing MOM5 will want to read all in the same field (so the need of combined them after re-gridding etc). Maybe @adele-morrison or @aekiss could advice here too if I missed anything.
are you using JRA55-do v.3 or a later version? Only 1.4 and later has separate solid and liquid runoff (but the model combines these before MOM sees them - see System description · COSIMA/access-om2 Wiki · GitHub)
I’m trying to set up a control_LH_Antwater experiment. I want the control runoff imposed at the surface but the anomalies to be prescribed at a chosen min/max depths and to be adjusted by the Gade line approach. Here we set min_depth=0 and max depth=40 to match with the control (i.e. we’re effectively prescribing the meltwater at the surface but using the existing code to do the temperature correction).
Investigating Pedro’s code for the basal_LH_brine experiment, I realised that calving flux in all our runs are imposed at surface, and the JRA55-do is the runoff passed at depth (here around line 3696). So I want to use this logic to set up control_LH_Antwater as following:
surface w/ temp. adjustment: Antwater anomaly and setting
Following that, I want to replace the following files:
- INPUT/ocean_month_output_GPC010_calving_365_final.nc → for a file containing it plus the original JRA55-do runoff. And that where my regridding issues are.
- v1-3/RYF.runoff_all.1990_1991.nc → for a file containing only the Antwater anomalies.
Some responses to your comments:
yes I realised I haven’t used conservative in my first attempt!
do you think regridding the calving to the JRA55 grid would be easier?
thanks for the link, it seems like we could have used that to create the MW perturbation.
Ah ok so with this approach you wouldn’t be using YATM to handle the JRA55 runoff forcing.
Therefore you’d need to be responsible for conservatively regridding JRA55 runoff onto the same grid as ocean_month_output_GPC010_calving_365_final.nc, and ensuring that all the water is mapped to ocean cells.
You’d also need to put all the Antwater anomalies on the same grid as RYF.runoff_all.1990_1991.nc if you don’t want to generate new mapping files.
So I think the liquid/river runoff - is still going through yatm (as its part of RYF.runoff_all.1990_1991.nc) but the meltwater runoff is handled seperately by ocean_month_output_GPC010_calving_365_final.nc ?
I think its important/easiest to use yatm for river runoff so that it spreads the runoff from high volume rivers. Without the spreading there would be issues with low salinity issues at those river mouths.
In the meltwater runoff, where there is overlap between the runoff and land :
a) then some sort of nearest neighbour algorithm could be used to move the water from land to the nearest adjacent cell. In OM3 we currently use a static remapping from land to ocean cells calculated using the BallTree functions from sklearn python package - this is the link but google research is probably more useful.
b) the problem with the BallTree approach is that it will just move water to the nearest ocean cell. It might be easier/better just to make some hand edits to move the water to the most appropriate ocean cell (accounting for the different in cell area between cells when moving the water around) - depending how many cells are impacted ofcourse
Good point Anton! Fabio, are you planning to put all the JRA55-do runoff directly into MOM (rather than via YATM), or just the runoff around Antarctica? I don’t think it would work to do it for all runoff globally, for the reasons Anton mentioned. And the river runoff is daily-varying, so that could be a lot of data to handle. Liquid and solid runoff are combined in JRA55-do v1.3, so that makes it awkward to handle them separately.
You could use YATM to handle the JRA55-do runoff globally, except with the Antarctic runoff scaled to zero using Tutorials · COSIMA/access-om2 Wiki · GitHub. Then you could apply just the Antarctic JRA55-do runoff directly into MOM in the way you want.
However, ACCESS-OM2 normally closes the water budget by imposing a constraint of zero net water flux into the combined ocean-sea ice system from the coupler (zero_net_water_coupler = true) by removing the area-mean of P − E + R (precipitation - evaporation + runoff) from P − E (also adjusting liquid_precip for consistency) so that the area-integrated P − E + R = 0.
If you’re injecting runoff without passing through the coupler, will your directly-injected runoff be missed in the water budget, leading to incorrect global closure with knock-on effects elsewhere?
Thanks all for your input @anton@aekiss. It sounds like this is more complex than I initially thought.
Though it look that the regridding works well (figure here), when I account for the land mask it becomes clear that most points with runoff values is located on land. (editting here to add a plot illustrating this; 3/4 of the runoff values are on land cells and only 1/4 is on ocean cells. Plot below has ocean (yellow) and land (purple) mask overlayed with some transparency by the regridded runoff in green-scale colormap:)
Thus, my thoughts is that this runoff/calving/basal split doesn’t affect the zero net water flux @aekiss ?
If that’s the case, and consider Andrew and Anton inputs here, I think we could do the following to make this work (tagging @adele-morrison here as well):
- JRA55-do runoff file modified to:
north of 60S: original JRA55-do runoff
south of 60S: replace original JRA55-do runoff for the Antwater meltwater ANOMALY
-Calving file modified to:
north of 60S: original calving flux
south of 60S: original calving flux + JRA55-do runoff
In the bold case, the JRA55-do runoff will need to be redirected to ocean cells manually. I will look into @anton suggestion here (BallTree nearest neighbour algorithm).
I think that’s true in the unperturbed case, since (if I understand correctly) it’s just splitting the runoff (input via the coupler from YATM, and therefore counted in the ocean budget) between basal and calving.
But what you’re proposing seems different, with JRA55 runoff bypassing the coupler, so it will be missing from the global water budget calculation, which may produce erroneous adjustment (extra global precip) to compensate?
My impression was that the JRA55 runoff being accounted in the calving array (point 1 in my earlier comment), then passed to river (point 2) would make it being accounted in the pme_river array (point 3) use for zero net water adjustment? Or did I miss something?
I think this is correct as it first defines calving = 0 too:
if(use_basal_module==.true.) then do i=isc,iec do j=jsc,jec if ( Grd%yt(i,j) < -60.0 ) then if(use_icb_module==.false.) then basal(i,j) = runoff(i,j) - calving(i,j) icb(i,j) = 0.0 runoff(i,j) = calving(i,j) calving(i,j) = 0.0
