open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

I’ve encountered an interesting problem relating to prescribing open boundary elevations using subroutine BORD in Telemac2D (v6.1).

Positive, temporally varying values of HBOR are fed back into the simulation from the BORD subroutine with no problem. The problem is that negative values of HBOR prescribed at the open boundary are replaced by a value of 0.

I’ve included a HBOR write-command into the end of the ‘loop on all boundary points’ section of BORD and this shows that the negative values of HBOR are definitely being passed back to Telemac2d so I presume my problem is located in the main program, not the Fortran file.

Exclusion of the PRESCRIBED ELEVATION keyword in the steering file results in a permanent open boundary elevation of 0 (I understand that a PRESCRIBED ELEVATION value is required, even when boundary elevations are being prescribed dynamically by BORD, to provide an elevation value for the first time-step?).

Negative boundary elevations are prescribed in the M2-wave case tutorial so I’m sure that it’s possible to prescribe negative values. I’ve compared the fortran files and cas files between the M2Wave case and my model and there appears to be no significant differences.

Here’s a list of the possible causes I’ve ruled out:

HBOR(K) = MAX( 0.D0 , Z-ZF(NBOR(K)) ) function  I removed this max function whilst modifying BORD (replacing it with HBOR(K) = Z-ZF(NBOR(K)))

PRESCRIBED ELEVATION keyword  The apparent minimum boundary elevation (i.e. 0) is not related to the keyword value.

PRESCRIBED ELEVATION given at four levels: Boundary Conditions file, Steering file, Open Boundaries file, Fortran file  The HBOR values output from BORD should be the last level at which elevations can be prescribed so I don’t understand why negative values are being made equal to 0. Even so, I checked whether this apparent limit is related to the HBOR values listed in the Boundary conditions file (=0 by default) and it’s definitely not.

Problems relating to bathymetry prescription at the boundary  I’ve double checked and all of my open boundary nodes have bathy values well below 0. I thought it might be a problem relating to the ‘ipobo’ component of the mesh (as defined in Blue Kenue) but Martin Serrer has stated that ipobo is automatically generated (post #2971) and Jean-Michel suggests that the IPOBO NPOIN array is never used (post #2849). Even so, it seems to me like this problem must be related to some sort of apparent depth limit on the open boundary nodes, possibly defined by the way in which free surface elevation and bathymetric depth are defined?!

Any help with this would be much appreciated, sorry for the long post, I thought it best to include all the available information. I’ve attached my Fortran file.

Thanks in advance,

Steve

Dear Steve,

by convention, water depth can never be negative. You can choose any reference for your bathymetry so that the values of the bathymetry (ZF) could be negative and consequently the free surface (SL) also can be negative. In all cases, H%R ( water depth everywhere) or HBOR (water depth on the boundary) are computed as = SL - ZF which is always positive.
MAX(0.0, Z-ZF) is introduced in bord.f in order to evoid a bad prescription of free surface (through subroutine SL or interpolated with subroutine STA_DIS_CUR) or the bathymetry ZF.
You mentioned the M2wave case where negative depth is prescribed, but I checked this case and what I found is the following:
AN= HB*cos(angle1) + HC*cos(angle2)
HBOR(NBORL(K)) =AN-ZF(NBORL(K))
which corresponds to what I explained earlier. Furthermore, we could be more safe and write
HBOR(NBORL(K)) = MaX (0.0,AN-ZF(NBORL(K)))

Try to verify if you have a prescribed free surface and not a water depth. In such case, you can freely prescribe negative values (of course with respect to negative bathymetry)

I hope that it was helpful.
Riadh

Hi riadh,

Thanks very much for your post, it helped me sort out the 'problem'.

You're right, HBOR is water depth, not free-surface level.
I'd got the wrong end of the stick because the positive values of HBOR output from BORD were equal to the free surface level. It turns out i'd overlooked the need to add a new variable named BOTTOM in the Blue Kenue Selafin file when exporting my mesh. Therefore my bathy values were 0 everywhere!

Thanks again,

Steve