Up to Transformations and interpolations
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
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 User Guide https://oasis.cerfacs.fr/wp-content/uploads/sites/114/2021/02/GLOBC_TR_oasis3mct_UserGuide_4.0.pdf2.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 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. Let me know if this help; Best regards, Laure
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
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
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
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 oasishelp@cerfacs.fr. Thanks, Best regards, Laure
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
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
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
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
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