Direkt zum Inhalt | Direkt zur Navigation

Personal tools

Sektionen
You are here: Home » FAQ & Forum » OASIS3-MCT forum » Transformations and interpolations with the SCRIP library in OASIS3-MCT » Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Up to Transformations and interpolations with the SCRIP library in OASIS3-MCT

Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at July 23. 2018

Hi,

I'm working on coupling the OpenIFS atmosphere model at T159/N80 resolution (reduced Gaussian grid) to the NEMO ocean model at ORCA05 (tripolar grid) resolution using OASIS3-MCT2.8.

The model runs ok, but the heat and water fluxes (radiative fluxes, sensible/latent heat fluxes, precipitation and evaporation) are not conserved.

Here's how I've set up the radiative, sensible and latent heat fluxes in the namcouple namelist

A_QsrMix:A_QnsMix O_QsrMix:O_QnsMix 7 10800 4 flxatmos EXPOUT

35718 1 722 511 atmo opat LAG=3600 SEQ=1

P 0 P 2

LOCTRANS SCRIPR MAPPING CONSERV INSTANT

BILINEAR D SCALAR LATITUDE 40 FRACNNEI FIRST

rmp_atmo_to_opat_BILINEAR_FRACNNEI_D_TL159_ORCA05.nc src

GLBPOS

QsrMix is net surface solar radiation and QnsMix is the non-solar radiation. I'm using the GLBPOS for the CONSERV option, which according to the OASIS documentation should lead to global conservation, but what happens is that QsrMix seems conserved while QnsMix has a constant offset of ca. 2 W/m2 in the global mean. I've tried using the CONSERV option for the SCRIPR remapping, but that fails. The error is "floating invalid" on the line 1054 of the "remap_conservativ.F" routine, which reads grid1_centroid_lat = grid1_centroid_lat/grid1_area so I'm guessing grid1_area is zero? Does anyone have any suggestions on how to get my global fluxes to be conserved? What is the difference between using conservative remapping and the GLBPOS option? If I have to use conservative remapping, does anyone know why it fails in my model?

Any help is much appreciated!

Many thanks! Joakim

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at August 01. 2018

Hi,

When using the SCRIPR option, you must provide the files grids.nc, masks.nc and if you are doing conserv remapping or using the CONSERV option, you must also provide the file areas.nc (see the documentation paragraph 2.3). Be awared that the areas of the source and the target grids must be in the same units.

The line for BILINEAR in your namcouple is wrong. You should put:

BILINEAR D SCALAR LATITUDE 1

And then apply CONSERV/GLBPOS to conserv the energy.

If you use the CONSERVATIVE (conserv) remapping of SCRIPR you should put the line in your namcouple :

CONSERV D SCALAR LATITUDE 40 FRACNNEI FIRST

In the case of conservative remapping, you must provide the corners with the longitudes and latitudes in grids.nc. If the coastline of your source and target grids are the same, the conserv remapping of SCRIPR is conservative, but it is usually not the case so you have also to use the CONSERV/GBLPOS option (see the documentation pp 33).

 Let me know if this help;

Best regards, Laure

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 04. 2018

Hi Laure

Thanks for your reply! I've tried exactly what you said, using

BILINEAR D SCALAR LATITUDE 1

and

CONSERV/GLBPOS

but I get really weird results.

I've activated EXPOUT to save exactly what is sent/received by each model component. Without the conservation option, the global water flux (precip-evaporation) sent from the atmosphere model is almost equal to what is received by the ocean model. When applying CONSERV/GLBPOS, the flux sent by the atmosphere is unchanged, but what is received by the ocean is completely different, and even has the opposite sign! Plotting the data on a map, it seems like the P-E differences get very exaggerated when using GLBPOS.

I've uploaded the masks, areas, grids files along with some plots of 1-month mean P-E field ("ATotRain" for atmosphere and "OTotRain" for ocean) as well as global sums each 3-hourly coupling step here: https://drive.google.com/drive/folders/1F0xrFAHQfc2xOgMRFmRwaaUmTSQKoFdN?usp=sharing

I'm at a loss for what the issue might be. Any help would be very much appreciated.

Best regards Joakim

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 06. 2018

Hi Joakim,

We have another user, Aurore Voldoire at CNRM, who had also some problems with this CONSERV/GLBPOS option.

She observed that the ratio calculated when using GLBPOS is not stable and can be equal time to time to 10 or -10 (because the numerator and the denominator are closed and small compared to the field).

So it seems that the CONSERV remapping is correct but she decided not to use GLBPOS option afterwards.

Do you have the same problems if you use the GLOBAL option ?

Best regards, Laure

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 08. 2018

Hi Laure

I've added two more plots to https://drive.google.com/drive/folders/1F0xrFAHQfc2xOgMRFmRwaaUmTSQKoFdN?usp=sharing showing what happens when I run with CONSERV/GLOBAL for the TotRain (precip-evap) variable. On a map, it looks kind of ok, but calculating the global sums, I find that the atmosphere model sends mostly negative values, i.e. global evaporation > global precipitation, but the ocean model receives the opposite! So the sign of global-mean P-E is reversed for most coupling steps. This is the same problem as when I used CONSERV/GLBPOS.

I also played around with the remapping, i.e. using GAUSWGT, BILINEAR, BICUBIC, or CONSERV, but it did not help. As you can see in my namcouple files in the link above, I'm using CONSERV/GLBPOS for remapping runoff from the land model to the runoff mapper, and this works perfectly! However, remapping from the runoff mapper to the ocean model using CONSERV/GLBPOS has the same problems as for TotRain. So any fields going to the ocean model become strange when using CONSERV/GLBPOS or CONSERV/GLOBAL.

If I remember correctly, CNRM use NEMO in their climate model as well, so maybe the problem arises when remapping to a NEMO tri-polar grid?

Best regards Joakim

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 11. 2018

Hi Joakim,

Thanks for your files. I will run the environment oasis3-mct/examples/test_interpolation with your masks.nc, areas.nc, grids.nc and namcouples. By the way this environment uses an analytical function and I am not sure I can reproduce your problem.

Would it be possible that you share with me a NetCDF file with your AToTRain var in it ? Please send me the link at [Email protection active, please enable JavaScript.].

Thanks, Best regards, Laure

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 20. 2018

Hi Joakim,

Do we agree that your observation that P-E change of sign is linked intrinsically to the CONSERV/GLOBAL method and is not a bug in the method ?

We are going to investigate the GLBPOS method to try to restrain the ratio (zlagr = av_sums / av_sumd) that multiplies the concerned field.

Best regards, Laure

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 20. 2018

Hi Laure

From what I can tell, when running without CONSERV/GLBPOS or GLOBAL, P-E sent from the atmosphere is almost the same what is received by the ocean. But when activating CONSERV, it becomes very different. For the first month of simulation, most of the 3hr coupling steps have negative global-mean P-E in the atmosphere, but this becomes positive in the ocean. So yes, activating CONSERV switches the sign of global-mean P-E in atm and ocean for most coupling steps.

For the ocean model, I've taken the grids, areas and masks data from another coupled model, KCM, which can run with CONSERV without problems. There could be something weird with my grid-cell areas for the atmosphere model, but since remapping from the atmosphere to the runoff mapper works fine with CONSERV/GLBPOS, I would guess that those are correct.

Let me know if you do some tests and figure something out.

Merry Christmas and Happy New Year! /Joakim

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 20. 2018

Hi Joakim,

Maybe there is something wrong with your areas. Be aware that the atmosphere and ocean areas must be in the same units.

Best regards and also Merry Christmas and Happy New Year to you ! Laure

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at December 21. 2018

Hi Laure I guess it could be. I've looked at the numbers, and they seem reasonable. For the atmosphere the grid cells are around 15000 km2, i.e. ~(122 km)^2, which makes sense for a N80 reduced gaussian grid. I'll double-check anyways. Cheers Joakim

Re: Global fluxes not conserved when using CONSERV GLBPOS in OASIS3-MCT2.8

Posted by Anonymous at March 19. 2019

Hi all,

Just to update (and possibly close) this issue. I have now managed to close the freshwater budget in OpenIFS + NEMO. To do this, I had to do two things:

1) Remove lakes from OpenIFS land-sea mask (OpenIFS treats lakes as ocean, but NEMO treats lakes as land).

2) Upgrade from OASIS3-MCT2.8 to OASIS3-MCT3.

When I put NLOGPRT=25 in my namcouple, OASIS control prints the global integrals of fields before and after conservation. This way I could check if OASIS was doing the GLBPOS conservation properly. I found that with OASIS3-MCT2.8 it did not look good at all, but with OASIS3-MCT3 everything is fine. I suspect there's a bug somewhere in MCT2.8, but I have no idea what the problem could be. Obviously GLBPOS still works well in MCT2.8 for some models, so I guess there's a certain combination of grids (e.g. reduced Gaussian...) that exposes this bug?

Best regards Joakim

Reply to this
URLs will be automatically hyperlinked. Basic HTML tags are OK.
Powered by Ploneboard
© Copyright ENES Portal 2011