Up to Transformations and interpolations
Hi Laure, Sophie, I have two questions. The first is about what oasis does about areas of the dest grid that are not covered by the source grid. In my setup there is a small area over the North pole which is not part of the atm domain (it uses a regular lat-lon grid). However the area does exist in the ice/ocean (it uses a tripolar grid). I have configured the oasis grids.nc to reflect this. I have not masked the area in either atm or ice/ocean masks.nc. What does oasis do in this case since there is effectively missing data? On a related note, is it OK if the corners in grids.nc effectively describe a triangle (rather than square)? This happens at the poles. My second question is about the generated remap files. I'm finding that it takes about 6 hours to create these. This is with 192x145 atm and 1440x1080 ocean. I have 7 remap files and they appear to be generated in serial. Is there any way to speed things up? Is there any documentation about the format of these files? Perhaps I could modify existing ones rather than regenerating everytime I make a small change to the grid or mask? It is slowing down my development cycle a lot. Also I'm planning on doubling my atm resolution and am concerned about how long this will take. Also is there a way to run the remap as a separate job to the model run? Presently I have > 1000 cores sitting around while just one calculates the remap files. Thanks for your help and your very useful product. Regards, Nic
Dear Nicholas, Do you use OASIS3 or OASIS3-MCT_2.0 ? - Concerning your first question about what oasis does about areas of the dest grid that are not covered by the source grid, it depends on the remapping your are using. If you are using DISTWGT, GAUSSWGT or BILINEAR or BICUBIC, these target points will receive the value of the nearest neighbour source point on the source grid. If you use CONSERVATIVE interpolation, this feature does not exist neither in OASIS3 nor OASIS3-MCT_2.0 and there should be missing data. This feature will exist for the CONSERVATIVE interpolation in the next version of OASIS3-MCT, OASIS3-MCT_3.0 that sould be available in december 2014. - Concerning your second question, if you still describe 4 corners at the North, with two identicals points, I think there is not problem. If your entire grid has only three corners then there are some modifications to do in the sources of oasis. Let me know. - Finally, you have a toy in the examples of OASIS3-MCT_2.0 (oasis3-mct/examples/test_rmp_esmf) to calculate the weights "offline" of the bilinear, patch (second order remapping), conservative and neareststod interpolation using ESM instead of the SCRIP library, and it is much more faster. I wrote several NCL (we have here version 6.2.0 of NCL) programs that uses ESMF. These weights are modified automatically at the end of the run to be used by oasis. For the moment it only runs on one process and I was not able yet to get the remapping files at the OASIS3-MCT format for the conservative interpolation, when at least one of the grid is unstructured. You just have to provide grids.nc and masks.nc and run the toy that corresponds to your case (you have a script to modify to run each toy). If you want to download the sources of OASIS3-MCT_2.0, please register on the OASIS web site at the address : https://oasis.cerfacs.fr/en/download-oasis3-mct-sources/ Best regards, Laure
Hi Laure, Thank you for your help. I'm particularly interested in your point about calculating the weights files offline using ESMF. I would like to do this but I have some reservations. It seems that ESMF can only do masking for logically rectangular grids. I am using a tri-polar grid. Do you have any comments about this? How do you get around this problem? Also it seems that ESMF does not do fracarea normalization, only destarea. Do you find this to be a an issue? On a related note, I've had a lot of trouble with SCRIP around the North Pole. There are a couple of grid points that have weights which are just wrong and will corrupt the coupling fields. I've noted mention of this here: https://oasis.cerfacs.fr/wp-content/uploads/sites/114/2021/02/GLOBC-Valcke_TR_OASIS3-MCT_2.0_2013.pdf section 4, under the heading 'precautions'. Also it is mentioned several times in this document: http://pantar.cerfacs.fr/globc/publication/technicalreport/2012/SCRIP_ESMF_LiYan.pdf Have you had any experience with this? Do you know what's going on here or how to get around it? I've found that backing off the whole grid from the pole (lat, lon and corners) solves the problem. But I consider this to be a hack. I'd like a better solution. This is one reason that I'm very interested in ESMF. The other is being able to generate the weights files quickly. Thanks for your time, Nic
Dear Nicholas, Concerning the conservative interpolation and the fracarea option, the remapping file of ESMF is destarea but the field in NCL is automatically normalized by the destination fraction (frac_b) (available in the remapping file of ESMF), so you have in fact a fracarea remapping when using NCL. In my NCL programs, where I create a remapping file for OASIS3-MCT from the ESMF file, I also normalize the weights of the remapping file by the destination fraction (frac_b), to be consistent with the SCRIP library. So I provide fracarea remapping. Again, be aware that I was not able yet to get the remapping files at the OASIS3-MCT format for the conservative interpolation, when at least one of the grid is unstructured. To end with, it is known that the SCRIP si not very good at the poles (linked to the algorithm). Best regards, Laure
