Is there an easy way to find the grid cell volumes of an entire grid? I'm looking to find the volume of a water mass and this would make things very simple.
I'm not sure I completely understand the geometry involved, so I'm having a hard time figuring out how to calculate it. Surely the code has to do this somewhere...
Thanks,
Rebecca
Grid cell volume
Hi!
I still use version 2.2, and don't know if anything has changed in the new version.
In mod_grid.F there are some variables defined, three of them are:
Hz: Thickness of vertical rho-Points
Huon: Total u-Momentum Flux term: interpolated(Hz)*u*dy (dy is the same as 1/pn, at least for a rectilinear grid, I don't know anything about curvilinear setups)
Hvom: interpolated(Hz)*v*dx
The 'allocate' functions in that file allocate N vertical levels for each i,j for each one of those variables.
Roms uses a staggered grid (see http://marine.rutgers.edu/po/documentat ... =technique ).
Hz is, as documented in mod_grid, the thickness at rho points (thickness means cell hight). But due to the staggered grid, there is a different thickness at the neighbouring u and v points.
For example, take the Finite-Volume formulation for a tracer. Tracers are defined on rho-points, so the cell must be constructed in a way that it's center is a rho-point. Now the in- and outflow of the cell has to be calculated, to update the tracer. The in- and outflow has to be calculated on the cell boundaries, and in the case of a staggered grid, that's where the u- and v- points are located. To calculate the inflow per second, one has to multiply area*velocitynormal*tracer. Area is dx*Height or dy*Height, but one needs the hight at VELOCITY-points, not at rho points, so one has to linearly interpolate Hz between neighbouring rho-point-Heights (e.g, in set_massflux).
One problem in the above explanation is that cell heights are changing during a 3d-timestep, and if I understood correctly, the massflux for calculating tracer-flux is averaged in fast barotropic time to the middle of the flux-period. That means, in the equation for tracer-update you will find the following cell-heights:
one in the middle of the cell at time n to calculate the old volume of the grid cell.
one in the middle of the cell at time n+1, to calculate new volume.
one at each boundary at time n+1/2, for the inflow-area.
The second of the above is also calculated with the barotropic time steps, but with different weights as the third.
See the Shchepetkin-McWilliams 2005 paper for more info.
For the momentum equations, things are similar, I think, exept that now the cell boundaries coincide with rho points, so no need to interpolate the cellheights.
The above is all simplified, but what I want to say is that one has to take care at what time and at what location to define the height.
I hope I could help you, I spent some weeks to find out what I just wrote (and even now i don't know if it's right or not...
)
--Stefan
I still use version 2.2, and don't know if anything has changed in the new version.
In mod_grid.F there are some variables defined, three of them are:
Hz: Thickness of vertical rho-Points
Huon: Total u-Momentum Flux term: interpolated(Hz)*u*dy (dy is the same as 1/pn, at least for a rectilinear grid, I don't know anything about curvilinear setups)
Hvom: interpolated(Hz)*v*dx
The 'allocate' functions in that file allocate N vertical levels for each i,j for each one of those variables.
Roms uses a staggered grid (see http://marine.rutgers.edu/po/documentat ... =technique ).
Hz is, as documented in mod_grid, the thickness at rho points (thickness means cell hight). But due to the staggered grid, there is a different thickness at the neighbouring u and v points.
For example, take the Finite-Volume formulation for a tracer. Tracers are defined on rho-points, so the cell must be constructed in a way that it's center is a rho-point. Now the in- and outflow of the cell has to be calculated, to update the tracer. The in- and outflow has to be calculated on the cell boundaries, and in the case of a staggered grid, that's where the u- and v- points are located. To calculate the inflow per second, one has to multiply area*velocitynormal*tracer. Area is dx*Height or dy*Height, but one needs the hight at VELOCITY-points, not at rho points, so one has to linearly interpolate Hz between neighbouring rho-point-Heights (e.g, in set_massflux).
One problem in the above explanation is that cell heights are changing during a 3d-timestep, and if I understood correctly, the massflux for calculating tracer-flux is averaged in fast barotropic time to the middle of the flux-period. That means, in the equation for tracer-update you will find the following cell-heights:
one in the middle of the cell at time n to calculate the old volume of the grid cell.
one in the middle of the cell at time n+1, to calculate new volume.
one at each boundary at time n+1/2, for the inflow-area.
The second of the above is also calculated with the barotropic time steps, but with different weights as the third.
See the Shchepetkin-McWilliams 2005 paper for more info.
For the momentum equations, things are similar, I think, exept that now the cell boundaries coincide with rho points, so no need to interpolate the cellheights.
The above is all simplified, but what I want to say is that one has to take care at what time and at what location to define the height.
I hope I could help you, I spent some weeks to find out what I just wrote (and even now i don't know if it's right or not...
)--Stefan
-
AlexisEspinosa
- Posts: 23
- Joined: Fri May 24, 2013 3:05 am
- Location: UWA
Re: Grid cell volume
Can Hz be saved in the history files?
Or is set_depth function the only way to obtain it for postprocessing?
Many thanks.
Alexis
Or is set_depth function the only way to obtain it for postprocessing?
Many thanks.
Alexis
Re: Grid cell volume
One could add the writing of Hz to def_his.F and wrt_his.F. You'd also have to invent an id tag for it, put it in varinfo.dat and read it where they get read. Also check the Hout(idHz) in read_phypar.F. You can grep for one like idDano to see how it's done. Note that Hernan believes the id tags should all be six characters long, so perhaps idHzee or idHzed? 
Most of us have postprocessing tools that know how to compute Hz, be it Matlab or whatever. Or one colleague asks me to write a static file of the z_rho, z_w appropriate for zeta=0 which I do with a Python script.
Most of us have postprocessing tools that know how to compute Hz, be it Matlab or whatever. Or one colleague asks me to write a static file of the z_rho, z_w appropriate for zeta=0 which I do with a Python script.