Closed boundary problem

Bug reports, work arounds and fixes

Moderators: arango, robertson

Post Reply
Message
Author
mathieu
Posts: 74
Joined: Fri Sep 17, 2004 2:22 pm
Location: Institut Rudjer Boskovic

Closed boundary problem

#1 Unread post by mathieu »

Suppose you run your model from initial state Initial.nc. Should the first record in the history file His_0001.nc coincide with Initial.nc? I would say so but this is definitely not the case.

For the sake of the argument, suppose that all boundaries of the rectangle (1:eta_rho,1:xi_rho) are closed, that is one has SOUTHERN_WALL, etc. Then the difference between two states is introduced in the t3dbc_tile function called from ini_fields.F.
There one has following code:

Code: Select all

      IF (Jstr.eq.1) THEN
!
!  Southern edge, closed boundary condition.
!
        DO k=1,N(ng)
          DO i=Istr,Iend
            t(i,Jstr-1,k,nout,itrc)=t(i,Jstr,k,nout,itrc)
            t(i,Jstr-1,k,nout,itrc)=t(i,Jstr1,k,nout,itrc)*            &
     &                              GRID(ng)%rmask(i,Jstr-1)
          END DO
        END DO
      END IF
What happens is that the layer (2,1:xi_rho) is copied on the layer (1,1:xi_rho). This is why the first record of history file is different from the initial state.

But there are more problems that this code introduces: some masked values can be copied onto the first layer since as far as I know there is no reason that mask_rho(2,iXi)=0 implies mask_rho(1,iXi)=0. In particular, this implies zero temperature and salinity.

Another problem is the dependence on the grid. Suppose that you have a grid with a full line of zeros, that is mask_rho(1,:)=0, mask_rho(:,1)=0, mask_rho(eta_rho,:)=0 or mask_rho(:,xi_rho)=0. Removing such lines from the grid file is not innocent and will led to different results even if all the forcing files have been correctly reduced as well.

I don't know if it is a bug or a feature. If it is a feature I would have appreciated that ROMS stops if it encounters a situation like mask_rho(2,iXi)=0 and mask_rho(1,iXi)=1.

User avatar
kate
Posts: 4088
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

Re: Closed boundary problem

#2 Unread post by kate »

mathieu wrote:I don't know if it is a bug or a feature. If it is a feature I would have appreciated that ROMS stops if it encounters a situation like mask_rho(2,iXi)=0 and mask_rho(1,iXi)=1.
I think of it more as the situation when mask_rho(1,j)=0 and mask_rho(0,j)=1, where i=0 is outside of the computational domain and part of the boundary conditions. You want your land mask to be zero just outside of the land parts of your domain.

User avatar
arango
Site Admin
Posts: 1349
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Closed boundary problem

#3 Unread post by arango »

Yes, this is correct. The initialization procedure in ROMS was changed when all the adjoint-based algorithms were introduced. See ini_fields.F for more details. We need to have a symmetric adjoint operator that it is run backwards. Therefore, the entire initialization procedure needs to be adjointable. Notice that we not longer need initial conditions for ubar and vbar. They are now computed by vertically integrating total velocity in ini_fields.F for consistency.

Usually, we never apply boundary conditions to the initial fields that are obtained via interpolation or objective analysis. If you want to see such fields, you still have the initialization NetCDF file. The ones in the history and restart files are consistent with ROMS dynamical kernel.

In closed boundaries, the no gradient conditions is correct for tracer in the finite differences discretization. The land/sea masking is application dependent and you are in full control of it.

Post Reply