Transport adjustment on the boundary

Report or discuss software problems and other woes

Moderators: arango, robertson

Post Reply
Message
Author
yj7054
Posts: 16
Joined: Mon Sep 24, 2018 7:40 pm
Location: CSIRO - Hobart Site

Transport adjustment on the boundary

#1 Unread post by yj7054 »

Hi All,

I realized that the volume transport the model got was different from the volume tranpsort which the boundary files provied. It seems that the model did some adjustment to keep the net volume balance in the domain regardless of the boundary files.

I did not turn on the VolCons to keep volume conservation. I knew it may be related with the boundary conditions, but I want to figure out how the boundary condition balance the net volume for me. Any comment is welcome, thank you very much!

The time series of volume transport got from boundary files (calculated by ubar&vbar, the upper one) and the model result (calculated by Huon&Hvom, the below one) is attached behind. The light blue line is the net transport from the three boundary, and the others are the transport from the east(deep blue), the south(green), the north(red) boundary, respectivly, with the west boundary closed.



Here is my boundary condition:
! 1 2 3 4

LBC(isFsur) == Clo Cha Cha Cha ! free-surface
LBC(isUbar) == Clo Fla Fla Fla ! 2D U-momentum
LBC(isVbar) == Clo Fla Fla Fla ! 2D V-momentum
LBC(isUvel) == Clo RadNud RadNud RadNud ! 3D U-momentum
LBC(isVvel) == Clo RadNud RadNud RadNud ! 3D V-momentum
LBC(isMtke) == Clo Rad Rad Rad ! mixing TKE

LBC(isTvar) == Clo RadNud RadNud RadNud \ ! temperature
Clo RadNud RadNud RadNud ! salinity
Attachments
transport_bry&output.png

jcwarner
Posts: 1172
Joined: Wed Dec 31, 2003 6:16 pm
Location: USGS, USA

Re: Transport adjustment on the boundary

#2 Unread post by jcwarner »

i am not really clear what the full story is. I dont use obc_volcons, that is to conserve volume in the domain. but it seems you are not using that. other than that, there is no guarantee that the volume flux across all open boundaries will balance. For example, if you had an estuary with only one open boundary then the flux will not balance. The fluxes across each open boundary are independent from other open boundaries (unless you activate vol cons).
-john

yj7054
Posts: 16
Joined: Mon Sep 24, 2018 7:40 pm
Location: CSIRO - Hobart Site

Re: Transport adjustment on the boundary

#3 Unread post by yj7054 »

jcwarner wrote:other than that, there is no guarantee that the volume flux across all open boundaries will balance. For example, if you had an estuary with only one open boundary then the flux will not balance. The fluxes across each open boundary are independent from other open boundaries (unless you activate vol cons).
-john
Thank you very much, John!

It should be what you said, but the volume flux on the boundaries calculated Huon&Hvom is different from the transport calculated by ubar&vbar on the boundary files. Besides, the time series of net volume changes are different from the boundary transport volume. I put another post before about calculating the volume conservation(viewtopic.php?f=17&t=5024). Could you please have a look if it is possible? :D

I am really confused by the volume conservation and transport in the model. :cry:

Yours,
Yi

jcwarner
Posts: 1172
Joined: Wed Dec 31, 2003 6:16 pm
Location: USGS, USA

Re: Transport adjustment on the boundary

#4 Unread post by jcwarner »

if you use flather boundary conditions (Fla), it does not guarantee that the mass flux imposed by the ubar on the boundary will be imposed at the boundary. For example one of the choices ends up with :
!
! Western edge, Flather boundary condition.
!
....
bry_val=BOUNDARY(ng)%ubar_west(j)
cff=1.0_r8/(0.5_r8*(GRID(ng)%h(Istr-1,j)+ &
& zeta(Istr-1,j,know)+ &
& GRID(ng)%h(Istr ,j)+ &
& zeta(Istr ,j,know)))
Cx=SQRT(g*cff)
ubar(Istr,j,kout)=bry_val- &
& Cx*(0.5_r8*(zeta(Istr-1,j,know)+ &
& zeta(Istr ,j,know))- &
& BOUNDARY(ng)%zeta_west(j))

so bry_val is ubar_west imposed on the boundary, but there are more terms:
ubar = bndry_ubar - sqrt(gh)*(zeta_boundary-zeta_model).
this allows some gravity wave energy to propagate out. It is not clamped. So the ubar*h you put on the boundary will not exactly be what the model uses. If you need it to be exact, then use clamped, but that is usually not very stable as we cant exactly predict the correct clamped values.
-j

yj7054
Posts: 16
Joined: Mon Sep 24, 2018 7:40 pm
Location: CSIRO - Hobart Site

Re: Transport adjustment on the boundary

#5 Unread post by yj7054 »

jcwarner wrote:if you use flather boundary conditions (Fla), it does not guarantee that the mass flux imposed by the ubar on the boundary will be imposed at the boundary.
-j
Hi John,

Thank you very much!

Excatlly, the ubar model calculated is usually different from what the OBCs provide in the boundary files. In the original post, my confuse was that why the net transport is roughly conservative. I knew they were different, but how the model controled the volume conservation without VolCons.

Maybe I can explain in this way. Because of the Radiation + Nudging Condition and the OBCFAC (I set 10.0 in the ocean.in), the open boundaries only care my inflow flux, and ignore the outflow flux (because of the radiation condition, outward information flows out through the boundaries freely). As a result, whatever the inflow information I gave the boundary will flow out, and it seems like the volume conservation. In fact, just as you said, there is no guarantee that the volume flux across all open boundaries will balance with VolCons truned off.

Do you think it make sence?

Kind Regard,
Yi

User avatar
wilkin
Posts: 875
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: Transport adjustment on the boundary

#6 Unread post by wilkin »

I'm not clear on why you are checking volume conservation in ROMS - I'm pretty sure we've had that working correctly for the last 10 years!

So really you're checking your own code and logic.

You had a post earlier about using Huon etc to compute transport, and you said you vertically integrated these. But really it's a vertical sum because the layer thickness is already in there. I hope you didn't put in an extra delta-z (Hz).

I'm not sure where you are going wrong, but it could be that Huon etc on the absolute perimeter of the domain are using the zeta from the boundary point which is computed only from boundary conditions and not the continuity equation.

How about you check your code for a control volume that is well inside the perimeter. There the line integral around the perimeter of ubar*(h+zeta), or the sum over k of Huon(k) should match the rate of change of zeta area integrated over the control volume.

Have you been careful not to have your i,j indices offset. The FORTRAN indexing is different from Matlab indexing.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

yj7054
Posts: 16
Joined: Mon Sep 24, 2018 7:40 pm
Location: CSIRO - Hobart Site

Re: Transport adjustment on the boundary

#7 Unread post by yj7054 »

wilkin wrote:You had a post earlier about using Huon etc to compute transport, and you said you vertically integrated these. But really it's a vertical sum because the layer thickness is already in there. I hope you didn't put in an extra delta-z (Hz).
Really thanks for your reply. I did not put in an extra delta-z (Hz) during calculating the volume transport on the boundary based on Huon/Hvom, and I just summed they up.

The result I put in that post (viewtopic.php?f=17&t=5024) is computed by 5-day average Huon/Hvom and 5-day history zeta, and they could not match. However, when I used the 1-timestep Huon/Hvom and 1-timestep zeta, they could match well (the attached figure). I still cannot figure it out.

And in fact, what I asked in this post is how the boundary keeps the water volume constant. The transport calculated by the input Huon/Hvom is really different from the transport calculated by the output ubar/vbar. For further discribing my question, I sent a email to you. Hope for your reply. Thank you very much! :D
Attachments
delt_volume&transport_timestep_notide_noriver.png

Post Reply