New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#1540 (Tracer conservation (2): Surface vertical velocity with source terms in hdivn) – NEMO

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#1540 closed Bug (invalid)

Tracer conservation (2): Surface vertical velocity with source terms in hdivn

Reported by: jchanut Owned by: nemo
Priority: normal Milestone:
Component: OCE Version: trunk
Severity: Keywords:
Cc:

Description

I have trouble to understand the rationale in including a source term with a barotropic component in the model divergence (this occurs with rivers and ice shelves in particular). Considering the continuity equation and z* coordinate, integrating vertically, we actually have an unusual cancellation of the river runoff contribution at the surface (while one should expect -(E-P-R) ).
The net component of river fluxes has already been accounted for in the volume variation, and its projection onto cell volumes is implicitly chosen to be uniform (in domvvl). This could be different, but its seems natural that all the terms in the barotropic equation are treated the same way in modifying the model thicknesses under the z* paradigm.
I suggest that the projection of the barotropic component due to river fluxes should be removed in the divergence term, which allows to recover right vertical fluxes (with expected w surface value). One simply add it in the sea level equation instead of summing vertically the divergence.
The existing code does conserve volume globally, but, I think, not locally, if one consider what is done in trasbc. To be discussed.

Commit History (0)

(No commits)

Change History (2)

comment:1 Changed 9 years ago by gm

  • Resolution set to invalid
  • Status changed from new to closed

The way runoffs are now (since v3.4 I think) are applied is identical to the way it is done when using an open boundary condition at the river mouths: this include a local change in the divergence of the velocity, and by consequence a divergence of the barotropic velocities.
In z* coordinate, the w represents the velocity across the levels, levels that are moving in time (z* ==> w=0 if only barotropic divergence or convergence is considered). The surface boundary condition is NOT w=-(E-P-R), but w=0. It is the time variation of the ssh which is equal to -(E-P-R).
I don't see any difference between the way a velocity divergence/convergence due to the dynamics is treated and the way runoffs are treated...
The existing code conserve BOTH locally and globally.

For what I read, there is no bug, and no major priority...
I close the ticket. If you have other questions/objections you can continue the discussion here. I will be happy to answer them.

Gurvan

comment:2 Changed 9 years ago by jchanut

Hi Gurvan,
Ok, we are considering two different things I think. To reformulate, what is disturbing to me is that we have two different kinematic conditions for w at z*=0 as diagnosed from the following lines in wzv:

      ELSE   ! z_star and linear free surface cases
         DO jk = jpkm1, 1, -1                       ! integrate from the bottom the hor. divergence
            ! computation of w
            wn(:,:,jk) = wn(:,:,jk+1) - (   fse3t_n(:,:,jk) * hdivn(:,:,jk)  &
               &                          + z1_2dt * ( fse3t_a(:,:,jk) - fse3t_b(:,:,jk) ) ) * tmask(:,:,jk)
         END DO
      ENDIF

, whether or not runoffs are considered outside or inside E-P flux. It does not however seem to be used in the z* version at least. Since by default, rivers are applied at the uppermost levels (which means that only the top value of w is concerned, but does not effectively enters advection), this is encouraging, still confusing. At noteworthy point for simplification even if the general case (ie setting runoffs over a certain depth) remains obscur to me.

Digging a bit deeper, it seems that what I experienced could be more related to the absence of correction of runoff fluxes and asselin filter in the code. Do you confirm at least this point ?
Jérôme

Note: See TracTickets for help on using tickets.