mesh_zgr inconsistency when using zps

[molines]

Hello,

In nemo_3.1, using partial steps, only the bottom most e3t and e3w are saved in mesh_zgr as 2D arrays. In order to use these fields, one should trust the mbathy field given in the same file.

The problem is that e3tp (and e3wp) (saved in domwri) are not corrected the same way that mbathy in zgr_bat_ctl: some points are eliminated (mbathy reset to lower value), but e3tp not changed.

The result is that when using the mesh_zgr.nc (v3.1) it is impossible in fact to retrieve the real 3D e3t or e3w or e3x.

This is very clear when computing a MOC, for instance !

A possible fix, is to update e3tp and e3wp ( AND hdept, hdepw ALSO! ) when a correction is done to mbathy.

By the way, for partial steps, when filling a 'pond' the new depth is actually set (impicitly) to the corresponding full step depth. Should it be better to set it to the minimum of the 4 neighbours ?

Jean-Marc

[molines]

After some use of mesh_zgr v3.1 ( with corrected e3t_ps etc ...) I finally arrive to another problem: for instance, when you want to compute the transport across a single zonal section. You only need the J position of the section plus the I_limits of the section. Then you extract e3v and vomecrty and that*s all ! With the 2D version of e3t_ps, you need to extract both J and J+1 in order to compute e3v. It produces a much more complicated and difficult to read program.

For the sake of simplicity I stongly advocate to turn back to 3D e3t e3u e3v and e3w in mesh_zgr. Or at list let it as choice in the namelist.

Jean-MArc

[smasson]

done, see changeset:1590
I add multiple choices to configure the meshmask file according to nmsh:

• MOD( nmsh, 3 ) gives you the number of files to be created (with 0 corresponding to 3)
  
• if nmsh <= 3 : we output 3D e3[tuvw] and gdep[tuvw]
  
• if nmsh <= 6 : we output 3D e3[tuvw] and 2D bottom gdep[tw]
  
• if nmsh > 6 : we output 2D bottom e3[tw] and gdep[tw]