Computing barotropic flux through a transect from daily averaged output

Hi, I’m using the CMEMS Mercator forecast/analysis product and was wondering if this is the right place to ask a question about the calculation of barotropic volume fluxes with the data that is available from there. If I understand the paper by Lellouche et al. ([3]), I think they use NEMO 3.1.

Currently I’m tyring to calculate the volume flux into the northern Bay of Bengal, northward of the zonal transect at 17 degrees north. I’m currently assuming that the mass/volume balance is:

dV/dt = \int_{transect} v dA + P - E + R

where

  • dV/dt is the change of volume due to free surface movements (variable ‘zos’ in the CMEMS Mercator notation)
  • v is the meridional velocity and the intergal is over the transect at 17 north.
  • P and E are precipitation and evaporation, respectively (see Eq. 6.3 in the Nemo manual [1])
  • R is the river runoff (which may be significant in the region, the runoff of the GBM delta alone has a climatological peak on the order of 0.1 Sv in late summer)

For velocity, I’m using daily averaged 3d meridional velocity (‘vo’ in the CMEMS Mercator notation). For ‘zos’ (free surface) I’m using daily averages too. The grid spacings are given by the e1t, e2t and e3t variables and the masks are available too from the static files ‘GLO-MFC_001_024_coordinates.nc’ and ‘GLO-MFC_001_024_mask_bathy.nc’.

For E and P, I’m using ERA5 data. For R, I’m using Dai and Trenberth 2002 data.

The problem is that the the volume flux through the boundary (first term on the RHS above, \int_{transect} v dA seems much too large. I’m getting volume fluxes on the order of 1 Sv throuhout the first three months of 2020. If i have done the calculation correclty, this would be equivalent to an absurd 5 m sea level rise in the domain within 3 months. Am I being naive about how to calculate this? Is it actually possible to do this type of calculation with daily averaged data? I’m aware that wave induced mean flow can in theory be a problem, but I guess this would be orders of magnitude smaller?

I have tried to stretch the vertical coordinate according to Eq. 2.24 in [2], although I have no clue which vertical coordinate the Mercator analysis/forecast product actually uses (the information is not in the user manual, unless I’ve missed it).

[1] https://www.nemo-ocean.eu/doc/node38.html
[2] Curvilinear generalised vertical coordinate System
[3] Lellouche, J. M., Greiner, E., Le Galloudec, O., Garric, G., Regnier, C., Drevillon, M., … & Le Traon, P. Y. (2018). Recent updates to the Copernicus Marine Service global ocean monitoring and forecasting real-time 1∕ 12 high-resolution system. Ocean Science, 14(5), 1093-1126.

Hi Stef,

I think the error could come indeed from the vertical coordinate system. Are you sure about e3t ?
Do the size of the array from the coordinates file fit that of the data ?
Also, a point that is important: the mean volume flow through a boundary is not the mean of e3t times the mean of the velocity if you use a non linear free surface, is it the case here ?

Hope this helps,

Robinson

Thanks for your reply!

Well I’ve plotted the transect data from which I do the calculations and found no obvious error. I plotted the transect including bottom, the vertical grid, the 3d velocity, the 2d velocity etc. and and it all looks reasonable - I should post the script here, but I’ll ask at the Mercator helpdesk first.

What I know nothing about are partial bottom grid cells.

Also, a point that is important: the mean volume flow through a boundary is not the mean of e3t times the mean of the velocity if you use a non linear free surface, is it the case here ?

Well, that’s what I meant when I wrote

Is it actually possible to do this type of calculation with daily averaged data? I’m aware that wave induced mean flow can in theory be a problem, but I guess this would be orders of magnitude smaller?

“wave-induced mean flow” means just that, and I think it would be orders of magnitude smaller than what I’m getting, but to be honest I have no clue what magnitudes to expect.

I’m going to try and ask at the Mercator helpdesk, although I have not had good luck with getting answers there. If I get lucky, I’ll report back.

I just realized something, where do you take the vertical scale factors from ? I understand you use an older version of Nemo, but I guess it uses partial steps. Therefore the vertical scale factor needs
to be a 3D field in order to take into account the partial step adjustment, and you need to take that from the meshmask file that was generated by the simulation.
About the wave flow, it really depends on the variability, but with tides the kind of Stokes drift it generates can lead you to enormous errors.

The current Mercator CMEMS forecast/analysis product does not simulate tides.

where do you take the vertical scale factors from ? I understand you use an older version of Nemo, but I guess it uses partial steps. Therefore the vertical scale factor needs to be a 3D field in order to take into account the partial step adjustment, and you need to take that from the meshmask file that was generated by the simulation

Good to know, I read about the partial steps in the NEMO documentation, but couldn’t find information on this in the CMEMS/Mercator product description and user manuals. In fact, I don’t think this data is available on the CMEMS website. At least I have not found it. I’ll have to ask the helpdesk.

Thanks again for all your help!

Regards, Stefan

Also, very important, do check what is the grid on which the Mercator data is provided.
If the data has been interpolated to a geographical grid then there is little chance that the volume fluxes
are conserved. It is important you use the original grid on which the simulations where made.

Awesome, I browsed through Lellouche et al. 2018 again and included the following points in the email to the helpdesk:

*) In Lellouche et. al (2018) [3] it says:
“The physical configuration is based on the tripolar ORCA12 grid type (Madec and Imbard, 1996) with a horizontal resolution of 9 km at the Equator, 7 km at Cape Hatteras (midlatitudes) and 2 km toward the Ross and Weddell seas.”
[5] is not available for free without subscription, but the abstract describes the mesh. Is there any non-conservative interpolation involved to generate the data that is downloadable via this portal? If yes, is there access to the variables on the original mesh so we can do more accurate mass/volume balances? Or was there some kind of conservative interpolation that would allow a mass/volume balance to be accurate on the provided 1/12 degree grids?

*) In Lellouche et. al (2018) [3] it says:
“A “partial cell” parameterization (Adcroft et al., 1997) is chosen for a better representation of the topographic floor (Barnier et al., 2006) and the momentum advection term is computed with the energy- and enstrophy-conserving scheme proposed by Arakawa and Lamb (1981).”
This looks like it could impact volume balances. Again, would this require access to the original mesh like the above point?

*) In Lellouche et. al (2018) [3] it says:
“Z coordinates are used on the vertical; the 50-level vertical discretization retained for this system has a decreasing resolution from 1 m at the surface to 450 m at the bottom and 22 levels within the upper 100 m.”
Is there any vertical stretching as described in [2]?

In the following see the entire ticket including references.


Hi, I’m using the CMEMS Mercator forecast/analysis product and I would like to make a calculation of barotropic volume fluxes. If I understand the paper by Lellouche et al. ([3]), I think the product is based on NEMO 3.1.

Currently I’m trying to calculate the volume flux into the northern Bay of Bengal, northward of the zonal transect at 17 degrees north. I’m currently assuming that the mass/volume balance is:

dV/dt = \int_{transect} v dA + P - E + R

where

*) dV/dt is the change of volume due to free surface movements (variable ‘zos’ in the CMEMS Mercator notation)
*) v is the meridional velocity and the integral is over the transect at 17 north.
*) P and E are precipitation and evaporation, respectively (see Eq. 6.3 in the Nemo manual [1])
*) R is the river runoff (which may be significant in the region, the runoff of the GBM delta alone has a climatological peak on the order of 0.1 Sv in late summer)

For velocity, I’m using daily averaged 3d meridional velocity (‘vo’ in the CMEMS Mercator notation). For ‘zos’ (free surface) I’m using daily averages too. The grid spacings are given by the e1t, e2t and e3t variables and the masks are available too from the static files ‘GLO-MFC_001_024_coordinates.nc’ and ‘GLO-MFC_001_024_mask_bathy.nc’.

For E and P, I’m using ERA5 data. For R, I’m using Dai and Trenberth 2002 data.

The problem is that the the volume flux through the boundary (first term on the RHS above, \int_{transect} v dA seems much too large, much larger than all other terms combined. I’m getting volume fluxes on the order of 1 Sv throughout the first three months of 2020. If i have done the calculation correctly, this would be equivalent to an absurd 5 m sea level rise in the domain within 3 months. Am I being naive about how to calculate this? Is it actually possible to do this type of calculation with daily averaged data? I’m aware that wave induced mean flow can in theory be a problem, but I guess this would be orders of magnitude smaller?

I have tried to stretch the vertical coordinate according to Eq. 2.24 in [2], although I have no clue which vertical coordinate the Mercator analysis/forecast product actually uses (the information is not in the user manual, unless I’ve missed it, but see the excerpt from Lellouche et al. (2018) below).

Here are some considerations that have been brought up in a nemo-ocean.discourse thread [4] where I asked the same question:

*) In Lellouche et. al (2018) [3] it says:
"The physical configuration is based on the tripolar ORCA12 grid type (Madec and Imbard, 1996) with a horizontal resolution of 9 km at the Equator, 7 km at Cape Hatteras (midlatitudes) and 2 km toward the Ross and Weddell seas."
[5] is not available for free without subscription, but the abstract describes the mesh. Is there any non-conservative interpolation involved to generate the data that is downloadable via this portal? If yes, is there access to the variables on the original mesh so we can do more accurate mass/volume balances? Or was there some kind of conservative interpolation?

*) In Lellouche et. al (2018) [3] it says:
"A “partial cell” parameterization (Adcroft et al., 1997) is chosen for a better representation of the topographic floor (Barnier et al., 2006) and the momentum advection term is computed with the energy- and enstrophy-conserving scheme proposed by Arakawa and Lamb (1981)."
This looks like it could impact volume balances. Again, would this require access to the original mesh like the above point?

*) In Lellouche et. al (2018) [3] it says: 
"Z coordinates are used on the vertical; the 50-level vertical discretization retained for this system has a decreasing resolution from 1 m at the surface to 450 m at the bottom and 22 levels within the upper 100 m."
Is there any vertical stretching as described in [2]?


Thanks so much for your kind help!

Regards, Stefan

[1] https://www.nemo-ocean.eu/doc/node38.html
[2] https://www.nemo-ocean.eu/doc/node9.html
[3] Lellouche, J. M., Greiner, E., Le Galloudec, O., Garric, G., Regnier, C., Drevillon, M., … & Le Traon, P. Y. (2018). Recent updates to the Copernicus Marine Service global ocean monitoring and forecasting real-time 1∕ 12 high-resolution system. Ocean Science, 14(5), 1093-1126.
[4] https://nemo-ocean.discourse.group/t/computing-barotropic-flux-through-a-transect-from-daily-averaged-output
[5] Madec, G. and Imbard, M.: A global ocean mesh to overcome the North Pole singularity, Clim. Dynam., 12, 381–388, 1996.

Wow, it seems the original grids are indeed available! In [1] they distinguish between

*) Product on standard grid (PGS)
*) Product on native grid (PGN)

and in [2] under the column “temporal coverage” they explicitly state if the grid uses a “standard grid”, so I guess those data sets where it doesn’t say “standard grid” are gridded on the native grid.

[1] Static files description - Mercator Océan - Ocean Forecasters

[2] https://www.mercator-ocean.eu/en/solutions-expertise/accessing-digital-data/product-details/?offer=4217979b-2662-329a-907c-602fdc69c3a3&system=d35404e4-40d3-59d6-3608-581c9495d86a

Hi Stef,

Sorry, I don’t think I have an exact answer to your problem, but I’ve also struggled with such calculations in the past. I just have a few points/ideas that hopefully can be helpful.

  1. GLORYS12 relies on NEMO running on a curvilinear grid (not regularl lat-lon). If you use data that is on a regular lat-lon grid, then the fields have been interpolated, so there might be errors related to that. Also, velocity fields are staggered (defined at cell interfaces, Arakawa C grid) in the NEMO dynamical core, but not in the publicly distributed GLORYS12 product, as far as I can remember.

  2. Mercator’s GLORYS12 user manual says this product uses 50 z levels, so I’m fairly confident this means that there is no vertical varying layers (“vvl”, else it would have been z^*). So, IMO the thickness of each vertical level does not vary in time. So, if all of this is true, using time averages (daily in your case) should be OK.

  3. Hopefully section 4.3 of the NEMO v3.6 documentation helps, particularly figure 4.5. I think GLORYS12 uses the (b) vertical discretisation from Fig. 4.5, which does include partial cells for the representation of bottom topography. At each location, the thickness of the deepest wet cell depends on the local bathymetry - so it varies in space. All other level’s thicknesses do not vary in space from one column to the other.

  4. There is a discrepancy between the precipitation/evaporation data you’re using and the one GLORYS12 had been forced with. First, GLORYS12 relies on ERA-Interim. Second, even using ERA-Interim, P would be correct, but not E because GLORYS12 computed the evaporation flux through the CORE bulk formula, which is not the same as ERA Interim’s. But there’s only so much you can do… :man_shrugging:

Good luck…

Thanks for your help! Very interesting.

Recently I’ve spent some time to read about data assimilation … I don’t fully understand it yet. But I wonder: is it possible that the assimilation system affects the volume fluxes in a way that makes it impossible to do such kind of volume-conservation calculations in the first place? If that’s true, it wouldn’t make sense to investigate the gridding issues any further…

1 Like