FSCLAMPED OBC

General scientific issues regarding ROMS

Moderators: arango, robertson

Post Reply
Message
Author
richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

FSCLAMPED OBC

#1 Post by richard.schmalz » Tue Feb 05, 2008 3:31 pm

FSCLAMPED Cases:

For all cases DT=20s ndtfast=20 with EAST, WEST, and SOUTH boundaries treated
the same. NORTH boundary is a solid wall. The following cpp options were used
for each of the FSCLAMPED open boundary cases.

Code: Select all

  ATM_PRESS          Impose atmospheric pressure onto sea surface.
  ANA_BSFLUX         Analytical kinematic bottom salinity flux.
  ANA_BTFLUX         Analytical kinematic bottom temperature flux.
  ANA_RAIN           Analytical rain fall rate.
  ANA_SSFLUX         Analytical kinematic surface salinity flux.
  ASSUMED_SHAPE      Using assumed-shape arrays.
  BULK_FLUXES        Surface bulk fluxes parametererization.
  CURVGRID           Orthogonal curvilinear grid.
  DJ_GRADPS          Parabolic Splines density Jacobian (Shchepetkin, 2002).
  DOUBLE_PRECISION   Double precision arithmetic.
  KANTHA_CLAYSON     Kantha and Clayson stability function formulation.
  LONGWAVE_OUT       Compute outgoing longwave radiation internally.
  MASKING            Land/Sea masking.
  MPI                MPI distributed-memory configuration.
  MY25_MIXING        Mellor/Yamada Level-2.5 mixing closure.
  NONLINEAR          Nonlinear Model.
  NONLIN_EOS         Nonlinear Equation of State for seawater.
  N2S2_HORAVG        Horizontal smoothing of buoyancy and shear.
  PERFECT_RESTART    Processing perfect restart variables.
  POWER_LAW          Power-law shape time-averaging barotropic filter.
  PROFILE            Time profiling activated .
  K_GSCHEME          Third-order upstream bias advection of TKE fields.
  RADIATION_2D       Use tangential phase speed in radiation conditions.
  !RST_SINGLE        Double precision fields in restart NetCDF file.
  SALINITY           Using salinity.
  SOLVE3D            Solving 3D Primitive Equations.
  SPLINES            Conservative parabolic spline reconstruction.
  STATIONS           Writing out station data.
  TS_U3HADVECTION    Third-order upstream bias horizontal advection of tracers.
  TS_SVADVECTION     Parabolic splines vertical advection of tracers.
  TS_NATURAL         Advective open boundary condition for tracers.
  TS_PSOURCE         Tracers point sources and sinks.
  UV_ADV             Advection of momentum.
  UV_COR             Coriolis term.
  UV_U3HADVECTION    Third-order upstream bias advection of momentum.
  UV_SADVECTION      Parabolic splines vertical advection of momentum.
  UV_LOGDRAG         Logarithmic bottom stress.
  Z0_SVAR            Variable Bottom Roughness.
  MET_OUT            (Pair,Uair,Vair) station/history file output.
  UV_PSOURCE         Mass point sources and sinks.
  VAR_RHO_2D         Variable density barotropic mode.

 Case 1: Model blow-up after order 2 to 2.5 days ~15000 time steps

  FSOBC_REDUCED      Using free-surface data in reduced physics condtions
  FSCLAMPED     free-surface, Clamped condition.
  M2REDUCED     2D momentum, reduced-physics condition.
  M3RADIATION   3D momentum, radiation condition.
  TNUDGING      tracers, passive/active outflow/inflow.
  TRADIATION    tracers, radiation condition.

Case 2: Model blow-up after order 1000 time steps

  FSCLAMPED     free-surface, Clamped condition.
  M2GRADIENT    2D momentum, gradient condition.
  M3RADIATION   3D momentum, radiation condition.
  TNUDGING      tracers, passive/active outflow/inflow.
  TRADIATION    tracers, radiation condition.

Case 3: Model blow-up after order 1000 time steps

  FSCLAMPED     free-surface, Clamped condition.
  M2GRADIENT    2D momentum, gradient condition.
  M3GRADIENT    3D momentum, gradient condition.
  TNUDGING      tracers, passive/active outflow/inflow.
  TRADIATION    tracers, radiation condition.
It should be noted that the model ran successfully for 15 days with the above
cppdef options using the following OBCS:

FSCHAPMAN
M2FLATHER
M3RADIATION
TNUDGING
TRADIATION

However, the water level signals near the boundary differed from the specified
water level signals significantly in the C&D Canal along the WEST open boundary
and to correct this I sought to investigate the FSCLAMPED boundary condition.

Any advice or suggestions would be much appreciated.

richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

#2 Post by richard.schmalz » Wed Feb 06, 2008 5:23 pm

I was wondering if the OBCS have been tested with all the different numeric options in the code. Is there a certain set of OBCs to use
for each set of numerics. Any information on this would be much appreciated.

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

#3 Post by jcwarner » Wed Feb 06, 2008 5:59 pm

I doubt that all the different types of BCs have been fully tested with all the different options available. You need to investigate why each of the different applications failed. I do not know the details of your test cases, but you should start simple and expand from there.
For example, perform a simulation with homogeneous flows first. maybe even just a 2D app, no psources, no cor, no adv, no bulk fluxes .... Just start simple, and add stuff as you go. You said that for each case it 'blew up" after xx time steps. Well, what does blow up mean? Did it fail at the boundary, at some interionr point? At a corner? You need to dig deeper as to why it failed because it is hard to give guidance without more info. So you need to run the model, if it blows up then restart it, and save more often until you can see eactly where / why it is happening.

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

#4 Post by arango » Wed Feb 06, 2008 6:28 pm

Your choice of clamping free-surface is not a good one :!: I am not surprised why your application is blowing-up. This option is available for multiple nesting applications. Recall that the free-surface is an expression for the vertically-integrated continuity equation. This will also affect the 3D continuity equation.

Your combination of open boundary conditions is not a good one. I actually recommend to not use radiation conditions in 3D momentum and tracers. It take a lot of effort to make this type of open boundary conditions to work. Several of us have been successful using clamped boundary conditions for 3D momentum and tracers with data from other models or climatologies in the input boundary NetCDF file.

I will never clamp free-surface neither 2D momentum :!: I use Flather boundary conditions. The reduced-physics boundary conditions requires some care. Notice that data is also needed for the Flather boundary conditions.

The radiation open boundary conditions are ill-possed. The passive/active options are possible but this requires a lot of fine-tunning.

richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

#5 Post by richard.schmalz » Wed Feb 06, 2008 7:46 pm

Thanks for the information, I will further study the problem.
As a general rule, as I understand your postings, if the model blows up Nans are generated for total energies and a restart file is written in netCDF, which probably contains a large number of Nans . As such it cannot be used to diagnose the problem.

Please refer to an earlier post, in which I now modify diag.F to set exit_flag=1 for any horizontal velocity component greater than 10 m/s and thus quit and write the restart file without the Nans.
In this manner, one may hopefully directly examine the restart file to see where the problem is without rerunning ROMS.

As it is now, one needs to rerun ROMS saving the restart file more often and perhaps at the timestep proceeding the blow up condition. A colleague of mine, then computes the u*dt/dx, v*dt/dy, and w*dt/dz over the vertical and selects the maximum value and plots these as 3 2d fields to examine the area of the problem if it is time step related.

The assumption is made, that by savings the fields sufficient for restart one may diagnose the problem. Has this ever turned out not to be the case and has it ever been necessary to institute debug print statement snippets and if so can these be made available.

Is my understanding of this procedure correct. In the diagnostics file, time-averaged quantities are written at certain intervals. Is there a way to select which fields are considered?

richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

#6 Post by richard.schmalz » Wed Feb 06, 2008 8:05 pm

With respect to the debug snippets, I was thinking along the lines of the following approach.

For each major cppdep option in the code, one writes a debug snippet, which is itself a cppdef option, which can be selected
to further diagnose problems.

For WET_DRY one has WET_DRY_SNIP to further debug this option.
Output would need to be written to a separate ascii file for example wet_dry_snip.out.

In further studying the cppdef options, I note one may select
DIAGNOSTICS_{BIO,UV,TS}. Would you recommend selecting these. If none are selected is the diagnostics file empty?

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

#7 Post by kate » Thu Feb 07, 2008 7:50 pm

You won't get a diagnostics file if you don't define any of them. If you do, you get a large file containing time averages of the individual terms in the equations, such as horizontal and vertical advection of the quantity.

If you know horizontally where to expect trouble, I'm finding the STATIONS option to be quite useful for debugging.

richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

#8 Post by richard.schmalz » Fri Feb 08, 2008 2:05 pm

With respect to the cppdefs for the snippets, it may be necessary to run the code in serial mode to facilitate the I/O. In the present ROMS, it looks like only the MASTER process can do the I/O.

What would be involved in implementing parallel I/O for the debug snippets?

richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

#9 Post by richard.schmalz » Fri Feb 08, 2008 2:26 pm

John and Kate: Many THANKS for your replies. I know you both probably work differently with different software, but would each of you give me more information on exactly how you debug the code?

John.....I believe you write out the restart fields at more frequent intervals into the restart netcdf file and then use software to plot or examine the fields (zeta, ubar, vbar, u, v, w) to examine where the
simulation blows up?

Kate....It sounds like in addition to this, you then use the stations option
to examine just the subsection of the grid where the problems are occurring. So in effect, you use a two-step process?

If one selects the DIAGNOSTICS option and sets NAVG=1, then in effect one gets snapshots, but one can only specify the start and interval for averaging, which would be one, thereby obtaining a large number of fields.

Have you used the ANA_DIAG cppdef for customized diagnostics? It appears that it is called at the end of the 3d equations timestep and as
now configured writes out time ,maximum (u,v) and (ubar,vbar) to a usrout file. It does not locate the (i,j) and (i,j,k) locations, which could be added. One could also check on (S,T) going out of range as well as zeta.

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

#10 Post by kate » Fri Feb 08, 2008 6:07 pm

OK, I think the ANA_DIAG is completely different from the DIAGNOSTICS_xx options. No, I have not used ANA_DIAG because I am the sort of user that drives Hernan crazy. I just go to the part of the code where I suspect trouble and add print statements.

I wrote up a debugging story (or two) on the ROMS blog: https://www.myroms.org/blog/
Note in the recent one, "just happened to have a station there" came about through much tearing of hair with the details of a crash depending on timestep, compiler, etc.

richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

#11 Post by richard.schmalz » Fri Apr 11, 2008 1:19 pm

I wanted to add some additional information to clarify my initial post. I discovered a problem with my initial zeta boundary conditions. The East and West boundaries were switched.

On the west boundaries 1-57 are open ocean and from 57 to 550 all is land except for C&D canal at 166-167.

On the east 1-81 are open ocean with everything above 81 being land.

For nonwater points, I specified zeta=0.

With the FLATHER/CHAPMAN bcs the code ran without any difficulties and the results were reasonable.

When I went to the FSCLAMPED and FSREDUCED, as I posted the model was unstable as I was specifying zero over water cells 58-81 on the east boundary, while for cells 1-57 the tidal signal was being specified.

In retrospect, it might be useful to specify zeta as nan or a large number at land points, so that if you make a mistake as I did, that you will catch it on your first simulation.

richard.schmalz
Posts: 24
Joined: Thu Oct 04, 2007 4:14 am
Location: NOAA

#12 Post by richard.schmalz » Fri Apr 11, 2008 1:27 pm

With the East and West Boundary Conditions corrected, Case 1 (in the initial post) ran successfully for both high flow and low flow 15 day hindcasts.

nobuhitomori
Posts: 22
Joined: Fri Jul 08, 2005 5:42 pm
Location: Kyoto University

#13 Post by nobuhitomori » Tue Apr 15, 2008 1:28 am

Here is summary of OBC for simple boundary conditions.
-> http://www.oceanwave.jp/research/ROMS/roms_obc.pdf
The best combinations for M2 educed physics are
FS -> clamped
M3 -> gradient

Please reduce to the simple module condtions and check the B.C. at
the end.

Post Reply