staggering of surface variables for coupling

[andreastorto]

Hello,

As I am not familiar with the wrf code,
I have a question about surface variables
exchanged through module_cpl.F,
namely in coupled configurations:

Are all variables following the T staggering,
even wind (sent to the ocean model) and ocean surface
currents (received)? Or these latter follow
U/V staggering?

Thanks in advance for the clarification

bests

 

[kwerner]

Hi,
In the module_cpl.F file, all variables (including wind variables) use mass point staggering. For example, around line 355, you'll see:

u_uo(ips:ipe,jps:jpe) = grid%u_phy(ips:ipe,kps,jps:jpe) - grid%uoce(ips:ipe,jps:jpe)

This is the effective wind speed in the x-direction, calculated to account for the speed of the wind and the speed of the top-level ocean current. Although typically U/V in WRF are typically found along the edges of the grid cell (and not in the center, like other variables), these particular U/V (u_phy and v_phy) have already been recalculated to the mass point (using averaging) in the physics routines.

 

[andreastorto]

Thanks a lot for the clarification,

there is something quite basic and trivial I miss, though.

I expect the grid of mass points to be of size (e_we-1,e_sn-1), as the size of e.g. XLONG, XLAT.

However, the cpl_oasis_define routine is communicating a grid size equal to (e_we, e_sn),
i.e. the staggered dimensions. Of course the initialization of the coupling interface aborts
due to this mismatch.

I wonder which are the lon/lat coordinates if the grid size of exchanged variables
is (e_we, e_sn) and not (e_we-1,e_sn-1),

(any link to documentation would be also very useful)

thanks in advance

 

[kwerner]

Hi,
Can you send your log file that shows the error message you are getting? Thanks.

 

[andreastorto]

Hello,

Please find attached the rsl.error.0000 (debug enabled)

the mass point grid is 192*116 = 22272 points while staggered dim is 193*117 = 22581.

The error occurs in a call to OASIS -> MCT

The dimension mismatch seems to occur (to me) because the grids.nc file
(needed by OASIS to define the grid geometry) refers to the 192*116 (mass point grid, where I find also the LANDMASK),
while actually the variable passed seems to be defined on a 193*117 grid.

I was expecting all the variables exchanged on mass point grid.

Thanks in advance

 

[davegill]

Andreas,
There is a comment within the WRF code that indicates that the size of the arrays to be passed to the OASIS model is the full dimension of the momentum variables.

In frame/module_cpl.F, subroutine cpl_snd2:

! we use ipe and not min(ipe, ide-1) the variable we are using are coming from grid and are therefore initialized to 0

This comment is consistent with the dimension sizes of arrays that get sent to the routines that are outside of the WRF system. Within the cpl_snd2 routine, all of the computations are (ips:ipe,jps:jpe), which is the size of the local dummy array cplsnd that is sent to subroutine cpl_sndfield:

REAL, DIMENSION( ips:ipe, jps:jpe ) :: cplsnd
.
.
CALL cpl_sndfield( grid%id, lltosend, ifldid, cplsnd )

The subroutine cpl_sndfield brings in the dummy array, now locally called pdata, and passes it to cpl_oasis_snd:

CALL cpl_oasis_snd( kdomwrf, jext, kfldid, nsecrun, pdata )

This routine then immediately sends the data to an external function/subroutine oasis_put:

CALL oasis_put(ssnd(kdomwrf,kdomext,kfldid)%nid, ksec,      pdata(:,:) , info)

During this coupling process, there are no steps where there is an attempt to reduce the size of the arrays to the mass point dimensions and the source code specifically mentions that this will not be done.

The OASIS coupling mechanism was graciously provided by an external contributor, and we are not really the experts.

Is it possible that the dimensioning error that is being reported is due to an inconsistency outside of the WRF model, i.e. the WRF model is actually doing the correct thing? Is there a coupling file, either source code or some text-based configuration file, where you need to explicitly include array sizes that are coming from WRF? Since the domain grid cell information does not appear to be part of the calling arguments in the final call to oasis_put and that information is mandatory, that external configuration file might be a place to look.

NCAR/MMM

 

[andreastorto]

Hello,

thanks for pointing this out,

I ve then fixed the problem by properly defining
the lon/lat/mask that OASIS needs to setup
the interpolation (with option SCRIPR, in files grids.nc masks.nc),
namely extending the mass point grid by 1 row and column
northward and eastward respectively.
These points are kind of "fake" but still needed then
(and should be set up properly since they are used for interpolation
coefficient setup).

Not clear however why this was done in WRF:
both variables and exchange procedures for OASIS
are basically hardcoded, so I don't see the need
to allow staggered variables when are not exchanged actually
(I may miss something though, or maybe it was conceived for very general purposes).

Thanks a lot for the support and best regards!