Regarding Tidal Input

Report or discuss software problems and other woes

Moderators: arango, robertson

Post Reply
Message
Author
nirnimesh
Posts: 27
Joined: Tue Sep 11, 2007 6:57 pm
Location: University of Washington
Contact:

Regarding Tidal Input

#1 Unread post by nirnimesh »

Hello Everybody

I am working on a ROMS(version 3.1-revision-262)-SWAN coupled system based on surf zone environment. Right now I am giving tidal input at the open boundary using a netcdf file and defining SSH_TIDES, UV_TIDES and RAMP_TIDES as my cppdefs.h options. I give all the major tidal constituents to ROMS based on a t_tide & harmonic analysis of tidal data collected from a NDBC/NOAA buoy. The tide simulated by ROMS is close to the observed tidal variability at a point with time but not same as observed data( differences of 30 cm). I am trying to compare the model results to measured data in field so a greater accuracy level is required. I tried to find a method by which we can provide the sea surface height at all the grid points at constant time intervals using a NETCDF file.

(a) In set_data.F file located in ROMS/Nonlinear,
# ifdef ZCLIMATOLOGY
!
!-----------------------------------------------------------------------
! Set sea surface height climatology (m).
!-----------------------------------------------------------------------
!
# ifdef ANA_SSH
CALL ana_ssh (ng, tile, iNLM)
# else
CALL set_2dfld_tile (ng, tile, iNLM, idSSHc, &
& LBi, UBi, LBj, UBj, &
& CLIMA(ng)%sshG, &
& CLIMA(ng)%ssh, &
& update)
# endif
# endif
This procedure should work for my case. But I am not sure what should be name and dimensions of the variables required.
(b) I also looked at http://www.myroms.org/index.php?page=initial which provides information about initial and climatological fields required. Here I didn’t find any description of 'idSSHc' or any other variable by which we can provide time varying sea surface height to ROMS.

My questions are:
(a) Is it feasible to provide time varying sea surface height to ROMS?
(b) If yes, what variables do I need to input in a netcdf forcing function?
(c) If yes, is ramping of sea surface required while going from one time level to next?

Thanks a lot
Nirni

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

Re: Regarding Tidal Input

#2 Unread post by kate »

If you provide a series of records for zeta to be read as the climatology, ROMS will do a linear time interpolation between them. Are you planning to nudge to your climatology when running the model? You'd want a pretty short nudging time for tides.

nirnimesh
Posts: 27
Joined: Tue Sep 11, 2007 6:57 pm
Location: University of Washington
Contact:

Re: Regarding Tidal Input

#3 Unread post by nirnimesh »

Kate

Thanks a lot for the reply.
I don't plan to nudge to my climatology.

I defined "ZCLIMATOLOGY" as cppdefs.h option in my *.h file. I also created an input netcdf file which provides 'zeta_time' and 'zeta' information to ROMS. The model runs smoothly and seems to take information from the file ( because it prints on the screen each time it takes data from the file as GET_2DFLD). When I look at the output, the zeta value is constant with time.

Can you suggest what am I doing wrong? Do I need to define anything else or provide some other option?

Thanking You
Nirni

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

Re: Regarding Tidal Input

#4 Unread post by kate »

Defining ZCLIMATOLOGY causes ROMS to read from the file, but it isn't then going to use that climatology unless you tell it how. I believe the only option provided with ROMS out of the box is that of nudging to the climatology. ROMS will be doing the full 2-D timestep which computes zeta consistently with the 2-D velocities. You could add code to have it replace zeta with the value from the climatology, but this doesn't really make sense unless you have those velocities and use them similarly. Are you planning on doing a full 3-D simulation?

You might instead go back to the way you were doing it before and consider how ROMS and the data disagree. Are the ROMS tides too big? Is there bottom drag and/or horizontal smoothing you can increase? Or are they too small? Are you getting the long-period contribution somehow?

nirnimesh
Posts: 27
Joined: Tue Sep 11, 2007 6:57 pm
Location: University of Washington
Contact:

Re: Regarding Tidal Input

#5 Unread post by nirnimesh »

Kate

Thanks for the description of the usage of ZCLIMATOLOGY. I am doing a full 3D simulation and after reading your reply it doesn't make sense to not use ZCLIMATOLOGY and use some other approach.

From the previous methods of using SSH_TIDES, ROMS Tides are neither too big or too small. I have a maximum differences of about 30 centimeters. This can be attributed to long term oscillation of the tidal signal. If I use that long term oscillation period, ROMS complains that tide period can't be greater than 100 hours. Since I am working on a surf zone environment, even a small difference in total depth causes a big changes in wave breaking criteria and generation of longshore currents. I have played with the bottom drag coefficient and right now I almost at the upper limit of drag coefficient observed in the surf zone, so I shouldn't be increasing that value.

I discussed the same issue with John Warner and he suggested to used tidal forcing at the open boundary with sea surface height. I am inputting zeta_east and zeta_time from a netcdf file to ROMS and my cppdefs.h options are as follows:

#define UV_VIS2
#define MIX_S_UV

#undef DIAGNOSTICS_UV
#undef AVERAGES
#undef AVERAGES_NEARSHORE
#undef AVERAGES_BEDLOAD

#define WET_DRY
#define NEARSHORE_MELLOR
#define SWAN_COUPLING
#ifdef SWAN_COUPLING
#define MCT_LIB
#endif


#define OUT_DOUBLE
#define UV_ADV
#define TS_MPDATA
#define DJ_GRADPS
#undef SALINITY
#define SOLVE3D
#define SPLINES

/* Boundary Conditions */
#define WAVE_BOUNDARY
#define NS_PERIODIC
#define EAST_FSGRADIENT
#define EAST_M2REDUCED
#define FSOBC_REDUCED

#define EAST_M3GRADIENT
#define EAST_TGRADIENT



#define WESTERN_WALL

#define MASKING

#undef ANA_GRID
#undef ANA_INITIAL
#define ANA_FSOBC
#define ANA_M2OBC
#undef ANA_SMFLUX
#undef UV_LOGDRAG
#define UV_QDRAG
#ifdef SOLVE3D
#undef SSW_BBL
# ifdef SSW_BBL
# define SSW_CALC_ZNOT
# undef SSW_LOGINT
# endif

# undef SEDIMENT
# ifdef SEDIMENT
# undef SED_MORPH
# define SUSPLOAD
# define BEDLOAD_MPM
# undef BEDLOAD_SOULSBY
# endif
# if defined SEDIMENT || defined SG_BBL || defined MB_BBL || defined SSW_BBL
# define ANA_SEDIMENT
# endif

# define ANA_STFLUX
# define ANA_SSFLUX
# define ANA_BPFLUX
# define ANA_BTFLUX
# define ANA_BSFLUX
# define ANA_SPFLUX
# define ANA_SRFLUX


# undef ANA_VMIX
# define GLS_MIXING
# if defined GLS_MIXING
# define KANTHA_CLAYSON
# define N2S2_HORAVG
# undef CRAIG_BANNER
# undef CHARNOK
# undef ZOS_HSIG
# undef TKE_WAVEDISS
# endif

#endif

I am still not getting correct results, but I would like to work on this approach till today evening and let you know the results. If you find something odd in the cppdefs.h options please let me know.

Thanks
Nirni

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

Re: Regarding Tidal Input

#6 Unread post by kate »

My comment about the long-period tides refers to the fact that if you don't include them, your tides can be off in both phase and amplitude, worst case being 30% in amplitude. John Wilkin apparently has some way to adjust the phase and amplitude when generating a tides file, but it would only be valid for a relatively short duration (year, not decades). You might ask him about it. Alternately, you can generate your zeta boundary condition file while including all of the long-period adjustments. Of course, this is just one possible source for the disagreement you see.

Post Reply