Up to Transformations and interpolations
Hello, I am still not sure to have understood the way to prepare input mapping files for OASIS and WRF+NEMO (option "MAPPING") with SCRIP. There are some info at https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?t=458 and https://www.cerfacs.fr/site-oasis/forum/oa_main.php?c=101 but are not fully clear and I'd like to understand if I do correctly, as I am not much expert of WRF. 1) coupled variables in WRF are defined on the mass grid (XLONG_M, XLAT_M) (?) but the dimension is extended (west_east_stag, south_north_stag). Which means for SCRIP and OASIS to work I have to manually extend the variables XLONG_M, XLAT_M, and CPLMASK to match the increased grid size. Not important the values of XLONG_M, XLAT_M in the last (easternmost and northernmost) grid points since the mask will be 0 anyway. This means that using directly XLONG_C and XLAT_C from WRF instead of extending XLONG_M and XLAT_M is wrong (as the variables use mass grid staggering). Is this correct? I am not quite sure and for irregular grids this is quite relevant. If not correct, this means I have to create different mapping files (with different lon lat and mask) for SST, UOCE, VOCE that would belong to differently staggered grids in WRF. 2) However, in the wrfinput_d01 file, the actual CPLMASK that needs to be included has dimension (west_east, south_north), so no need to extend it while running the coupled model. Is this correct? Thank you very much in advance, andrea
Hi Andrea, Your reasoning seems right to me. The grids and masks provided to oasis in grids.nc and masks.nc have to match the shape of the vector containing the coupling fields. So if your coupled variables in WRF are provided on the extended grid, everything (grid lat, lon, mask, etc) has to be defined on that extended grid. I hope this helps? Regards, Sophie
Hi Sophie, thanks for the quick reply. Definitively, it helps me a lot. I am still not fully sure about the staggering of variables in WRF. I assume they are on the mass field grid but the fact they use an extended grid makes me doubt. I could dig more in the WRF code but if someone has a more authoritative answer it would be great, since the OASIS interface in WRF seems to be broadly used. I think this is crucial to setup the interpolation weights correctly. thank you very much, best, andrea
The OASIS coupling interface in WRF is currently dealing only with mass fiels (non-staggered variables). The trick is that, internally, WRF is using arrays with extended dimensions whatever the field (staggered or not). This ensures that all arrays have the same size which is a great simplification in the code. -> WRF non-staggered variables will be automatically extended inside the code. All non-staggered variables are not extended in WRF input/output files but will be extended once they are read by the code. That’s why CPLMASK in wrfinput_d01 is not extended. -> OASIS is exchanging WRF arrays during the simulation which are “internal” arrays with extended dimensions. OASIS is therefore only dealing with extended arrays and its input files must then be compatible with extended arrays (even for mass fields). Sébastien Masson
Thanks a lot Sébastien for this clarification, it really helps me! I have an additional doubt about vector fields, though. In my suite, NEMO configuration is regular lon-lat, while WRF is not, and locally angles from the two grids may be significantly different from zero. Is the OASIS interface handling this situation, i.e. unrotating wind stress fields before passing them to NEMO? (the same for currents, of course, although probably less important). From a quick look to the interface code, it seems to me it does not, while from the OASIS documentation, the coupler code is not handling this either. So do you have any suggestion how to handle this in the code? Should I consider unrotating them in the NEMO code through reading the angles in a file? However, this is a quite standard issue I suppose, so I wonder if there is a clean or already implemented option to do so, Thank you very much, best, Andrea
Hello, As written in the User Guide (see "Support of vector fields with the SCRIPR remappings" in section 4.3), the coupler does not handle the rotation of the vector field. You have to follow what is suggested in the User Guide: "Vector mapping is NOT supported and will not be supported by OASIS3-MCT. For proper treatment of vector fields, the source code has to send the 3 components of the vector projected in a Cartesian coordinate system as separate fields. The target code has to received the 3 interpolated Cartesian components and recombine them to get the proper vector field." In NEMO, this is done in subroutine rot_rep, see NEMO/OPA_SRC/SBC/geo2ocean.F90 . Let me know if this is not clear, Sophie
Hello, Thanks for the clarification, Sophie. I am still a bit confused about the WRF part. I see that NEMO allows for vector rotation through specifying either "local grid" (=no rotation needed) or "eastward-northward" (then rotation is performed, assuming received fields in lon-lat) in the namelist. For instance, in my NEMO namsbc_cpl namelist I have [...] ! description | multiple | reference | orientation | grid sn_rcv_tau = 'oce only' , 'no' , 'spherical' , 'local grid' , 'T' [...] In my case, this should not have effect in practice, as the NEMO grid is a lon/lat regular regional domain, but in general it should be "eastward-northward" I guess, unless the atm and oce grids coincide. However, in the WRF interface to OASIS, there is no option to rotate the wind stress. As I am using a Lambert Conformal grid, this could be relevant in some parts of the domain. What I am not sure: the OASIS interface of WRF uses the variables grid%u_phy grid%v_phy to define the wind stress vector. It is not clear if these are defined in the local WRF grid or with east-north orientation. I guess in the local WRF grid as usual WRF wind outputs, so that a rotation procedure should be added to the WRF interface. Do you know if this is correct? Thank you very much, Andrea
Hi, Yes I would say this is correct but I let WRF experts comment, as I do not know anything about WRF code. Regards, Sophie
Hello Andrea, I'm not an expert of WRF, either. However, I'm coupling COSMO-CLM with NEMO using OASIS3-MCT, and COSMO-CLM also has a rotated grid. What I have done is to rotate the wind components onto a regular lat-lon grid before sending them to OASIS. Luckily, inside the COSMO-CLM source code there is a function to do the rotation. In NEMO's namelist I set: sn_rcv_tau = 'mixed oce-ice' , 'no' , 'spherical' , 'eastward-northward', 'U,V' meaning I kept the u and v wind components on the U and V grids, respectively. In case you use grid T in the namelist, you should provide the u and v of WRF on the grid T, too. I hope this answer may help. Best regards, Ha
Thanks a lot Ha, in my case OASIS will interpolate from mass grid in WRF to T grid in NEMO. I understand WRF stores the angles w.r.t. to the Earth orientation in the variables SINALPHA and COSALPHA. So if the reasoning is correct, we should substitute: File frame/module_cpl.F Line 364 cplsnd(ips:ipe,jps:jpe) = taut(ips:ipe,jps:jpe) * u_uo(ips:ipe,jps:jpe) / wspd(ips:ipe,jps:jpe) with cplsnd(ips:ipe,jps:jpe) = taut(ips:ipe,jps:jpe) * ( u_uo(ips:ipe,jps:jpe)*grid%cosa(ips:ipe,jps:jpe)- v_vo(ips:ipe,jps:jpe)*grid%sina(ips:ipe,jps:jpe) ) / wspd(ips:ipe,jps:jpe) And Line 371, substitute cplsnd(ips:ipe,jps:jpe) = taut(ips:ipe,jps:jpe) * v_vo(ips:ipe,jps:jpe) / wspd(ips:ipe,jps:jpe) with cplsnd(ips:ipe,jps:jpe) = taut(ips:ipe,jps:jpe) * (u_uo(ips:ipe,jps:jpe)*grid%sina(ips:ipe,jps:jpe)+v_vo(ips:ipe,jps:jpe)*grid%sina(ips:ipe,jps:jpe)) / wspd(ips:ipe,jps:jpe) If any WRF user could confirm, it would be great, Many thanks Andrea
Hi all, I cannot comment the details about the WRF implementation but I would like to stress that rotating to a lat-lon grid and then passing the components to OASIS is not enough. A I wrote above: "For proper treatment of vector fields, the source code has to send the 3 components of the vector projected in a Cartesian coordinate system as separate fields. The target code has to received the 3 interpolated Cartesian components and recombine them to get the proper vector field." Regards, Sophie
Thanks Sophie, I am a bit confused by your comment: in the example above, the wind stress has no vertical component to be passed by WRF, and I thought NEMO can handle such a case when we have "spherical" and not "cartesian" reference (file sbccpl.F90 of NEMO). But I am not sure whether this is what you meant. Thanks, andrea
Hi again, NEMO itself is able to handle spherical components of a vector. But the regridding/inyterpolation of the vector to another grid by OASIS (or by any other coupler) will NOT be OK if you provide the local or spherical components of the vector as 2 different coupling fields. What you have to do is to project the vector in a cartesian coordinate system, and then pass the 3 resulting cartesian coordinate system components as 3 different coupling fields. Then on the target grid, after coupling and regridding/inyterpolation you have to transform the vector from the cartesian coordinate system to the local or spherical system used in the target model. I hope this is clearer? Sophie
Sorry for the late response, I did not see that the discussion did not end after my first response. @andrea: You are right. If WRF and NEMO are not sharing the same grid orientation, you must rotate the vector components with the eastward-northward orientation before sending them to OASIS. Once received the eastward-northward vectors will be re-rotated on the local grid (if needed). You can see the eastward-northward orientation as an intermediate and common orientation (know by each model) that is therefore used to exchange vector fields (from WRF to NEMO for the wind and from NEMO to WRF for the current). Note that if WRF and NEMO are using the same rotated grid (so the both know it), there is no need to use the eastward-northward rotation. As you saw, this vector rotation is not coded in the reference version of WRF. I coded it in a development branch that I must send back to WRF people for more than a year!… I should do it… you can find it here: https://github.com/massonseb/WRF/blob/update_coupling/frame/module_cpl.F You will se that the modifications correspond to the ones you proposed on Nov 29th. @Sophie: Using cartesian coordinates is quite heavy (costly change of coordinate system and more fields to exchange). I think the main motivation of using a 3D coordinates system is to avoid any problem near the pole which presents a singularity for the eastward-northward coordinates system (for example we may have some issues in the wind curl around the north pole). However I never seen a clear demonstration of the real benefit of using the cartesian coordinates… Do you have one reference of some plots which show that? In regional configuration (excluding the north pole region) I thing this extra work is not needed. How can I get automatically informed on the post on this discussion thread? Sébastien Masson
Hi again, Yes Sébastien I agree that using cartesian coordinates is quite heavy and it becomes important only near the pole so not for regional configurations excluding the pole. Even for global configurations, I have no clear demonstration of the benefit, I agree that the concept is more theoretical than practical. Sophie Valcke
Hi Both, Thanks a lot Sébastien for explaining/confirming the issue and sharing the updated code, I'll switch to it for consistency with future versions. PS: when you register to OASIS for download https://oasis.cerfacs.fr/en/download-oasis3-mct-sources/ you are asked whether you want to receive notification of new forum topics/messages, Best, andrea
