Problem using M2CLAMPED

[paim_oceano]

Dear all,

I am running a test case to better understand the impact of different kinds of Boundary Conditions and found something that I cannot understand.

My scenarios are:
S1 - FSCHAPMAN - M2FLATHER
S2 - FSCHAPMAN - M2CLAMPED
S3 - FSCLAMPED - M2FLATHER
S4 - FSCLAMPED - M2CLAMPED

(Meaning I am using, in S1, something like:
#define EAST_FSCHAPMAN
#define EAST_M2FLATHER)

In my Test1, I am forcing my grid with a varying UBAR coming from the East Boundary.
(In all the tests I have no tide or wind)
In this case, scenarios S1 and S3 generate currents and sea surface elevation, while scenarios S2 and S4 generate zero fields (actually, values around E-08 to zeta and E-06 to ubar).

In my Test2, I forced the model with a Sea Surface Elevation coming from the same East boundary and no ubar. In this case, all the scenarios generate results.

I don't know if I understood it wrongly, but in the Technical Manual the Clamped boundary condition entry reads:
"Almost as simple is setting the boundary value to a known exterior value." and then says that Phi equals to external Phi (I'm assuming that Phi in here represents any variable).

So, shouldn't this means that the UBAR in the first cell inside the grid should be exactly equal to the value of UBAR in the boundary file?
Any idea about why I'm getting these zero results?

Thanks in advance. =)

Andre Rodrigues

[kate]

The modern code in u2dbc_im.F looks like:

Code: Select all

!
!  Eastern edge, clamped boundary condition.
!
        ELSE IF (LBC(ieast,isUbar,ng)%clamped) THEN 
          DO j=Jstr,Jend
            IF (LBC_apply(ng)%east(j)) THEN 
              ubar(Iend+1,j,kout)=BOUNDARY(ng)%ubar_east(j)

Yes, the edge value is being set to the boundary condition. Since your code dates to the cpp era of boundary condition choices, you can look in the $SCRATCH_DIR/u2dbc_im.f90 file to see if similar code is there. If so, perhaps you can try a print statement to see if ubar_east is what you thought it should be.

That said, I'm not sure why someone just getting started with ROMS would use an old version - our problems will not match your problems.

[wilkin]

Check the standard output ("log file") to see if you are actually reading the the ubar_east data.

Right after reading the initial conditions there should be a report something like:

Code: Select all

    GET_NGFLD   - 2D u-momentum eastern boundary condition,  t =   5 00:00:00
                   (Rec=0000005, Index=2, File: your_boundary_file.nc)
                   (Tmin=          0.0000 Tmax=        60.0000)
                   (Min = -1.0000E-01 Max =  9.0000E-02)

...with sensible values for Min and Max.

ROMS will only read boundary data if it has a set of instructions that will require the data be used.

[paim_oceano]

Guys,

I'm sorry, I just realized I explained my case wrongly and I didn't mention that I am using COAWST. It is actually when I force the model with the Sea Surface Elevation that I get the problem, not when forcing with the U-component of the Barotropic Flow.

That is what confused me the most. Why would the Barotropic Flow Boundary Condition affect so much a scenario where I am imposing only Surface Elevation at the boundary?
If I make only this change in my header file, from:

Code: Select all

/*#define EAST_M2FLATHER*/
#define EAST_M2CLAMPED 

to

Code: Select all

#define EAST_M2FLATHER
/*#define EAST_M2CLAMPED/* 

and leave everything else exactly the same, I get results.


Wilkin,

I've found the part in the log you mentioned and it seems the model is reading the forcing:

Code: Select all

    GET_NGFLD   - free-surface eastern boundary condition,   t =     0 02:00:00
                   (Rec=0003, Index=2, File: delbay_bry_Esin_2a_12ph.nc)
                   (Tmin=          0.0000 Tmax=         30.0000)
                   (Min =  1.68294197E+00 Max =  1.68294197E+00)

The Min and Max values change with time and match the values I am imposing at the boundary.


Kate,

Actually I agree that using an older version is not the wiser option, but I am trying to replicate the results another member of my group got a while ago. Afterwards, we intend to move on to the latest releases.

Since the problem is actually in zeta and not u2, I looked into the code in zetabc.F and found this:

Code: Select all

# elif defined EAST_FSCLAMPED
!
!  Eastern edge, clamped boundary condition.
!
        DO j=Jstr,Jend
          zeta(Iend+1,j,kout)=BOUNDARY(ng)%zeta_east(j)
#  ifdef MASKING
          zeta(Iend+1,j,kout)=zeta(Iend+1,j,kout)*                      &
     &                        GRID(ng)%rmask(Iend+1,j)
#  endif

While in the newer version, this area is like this:

Code: Select all

!
!  Eastern edge, clamped boundary condition.
!
        ELSE IF (LBC(ieast,isFsur,ng)%clamped) THEN
          DO j=Jstr,Jend
            IF (LBC_apply(ng)%east(j)) THEN
              zeta(Iend+1,j,kout)=BOUNDARY(ng)%zeta_east(j)
#ifdef MASKING
              zeta(Iend+1,j,kout)=zeta(Iend+1,j,kout)*                  &
     &                            GRID(ng)%rmask(Iend+1,j)
#endif
            END IF

Apart from the IF part, the definition of the value seems to be the same.

Could it be that the information about the Barotropic Flow takes precedence over the Surface Elevation and since I am applying ubar equals zero in a clamped BC, the model kills any movement at the border and therefore kills also the elevation?

Thanks again

[kate]

Yes, it could be that clamping ubar to zero will negate any influence of a sea surface elevation boundary condition.

[wilkin]

Because of the arrangement of the ROMS C-grid, with the last column of zeta points being outside the "physical" domain defined by the last column of normal velocity points (u on an east boundary), setting zeta_east and only zeta_east on the boundary has virtually no impact on the flow. This is because the two zeta points on, and one point inside, the boundary straddle the boundary ubar. Any effect your zeta_east might have on the x-direction pressure gradient driving ubar will be rejected if you clamp boundary ubar to zero.

I recommend you use the Chapman/Flather combo like almost everyone else does. It's very robust. I would not try other options unless convinced that the Chapman/Flather approach is demonstrably failing for your application.

[paim_oceano]

Thanks a lot guys. This was very helping and enlightening.

[paim_oceano]

One last questions.
Would I run into the same situation if I was putting my forcing in the East/South boundary or is this a problem specific for West/North boundary?

[kate]

For east and west, the ubar boundary can shut things down. Same with vbar on the north and south.

In all cases, the 2-D velocity is a stronger constraint on the solution because zeta is computed from changes in convergence/divergence.

[paim_oceano]

Ok. Thanks a lot for your reply =)