# RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo - Forum - XBeach

**crash or bug**, please remember to

**include**an entire

**model setup**in your post that reproduces the crash or exposes the bug. Also add the

**XBlog.txt**file. This is necessary information for people that are trying to help you. Including your model setup can be achieved by adding the zipped run directory (excluding output) as an attachment to the post.

## Forum

# Breadcrumbs

- Home
- Running XBeach
- RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo

### RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo

CT

##### Christophe Troch, modified 1 Year ago.

#### Hm0 output larger than Jonswap input at boundary for Non Hydrostatic model

Capillary Posts: 2 Join Date: 2/9/17 Recent Posts
00

Please sign in to flag this as inappropriate.

Hi Everyone,

The Hm0 always seem to be larger than the Jonswap input specified at the boundary when analyzing the water levels at the input boundary when running the Non Hydrostatic model. This seems to get worse with longer period waves (Tp = 14, 16, 18).

Attached is a small flume test to show the results. A Jonswap spectrum with a Hm0 = 3m, Tp =12 is specified as input. Calculating the Hm0 using the water level time series output 50 m from the offshore boundary, the Hm0 = 3.5052m. Attached is a plot showing the two spectra, the specified Jonswap input, and the Jonswap output.

When running the same test, with same parameters, only changing the wave period, the results are: Input Hm0 = 3 m, output Hm0 = 4.5 m.

It seems as if this could be a reflection problem, since when I use Wall or Neumann for the lateral boundaries, both shows the same amount of reflection. Attached is a Hm0 plot calculated from the water level for a 3m wave input. If anyone could shed some light on what could be the cause of this, it will be much appreciated.

Attached you could find the setup with the input parameters.

Kind Regards,

Chris

The Hm0 always seem to be larger than the Jonswap input specified at the boundary when analyzing the water levels at the input boundary when running the Non Hydrostatic model. This seems to get worse with longer period waves (Tp = 14, 16, 18).

Attached is a small flume test to show the results. A Jonswap spectrum with a Hm0 = 3m, Tp =12 is specified as input. Calculating the Hm0 using the water level time series output 50 m from the offshore boundary, the Hm0 = 3.5052m. Attached is a plot showing the two spectra, the specified Jonswap input, and the Jonswap output.

When running the same test, with same parameters, only changing the wave period, the results are: Input Hm0 = 3 m, output Hm0 = 4.5 m.

It seems as if this could be a reflection problem, since when I use Wall or Neumann for the lateral boundaries, both shows the same amount of reflection. Attached is a Hm0 plot calculated from the water level for a 3m wave input. If anyone could shed some light on what could be the cause of this, it will be much appreciated.

Attached you could find the setup with the input parameters.

Kind Regards,

Chris

non-hydrostatic
offshore
nonh
hm0
jonswap
boundary
larger
reflection
neumann

##### Guilherme Passos, modified 1 Year ago.

#### RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo

Capillary Posts: 22 Join Date: 12/4/12 Recent Posts
00

Please sign in to flag this as inappropriate.

Hello Christophe,

If It's a reflection problem, I had some issues with this too a time ago. Try to set "front = waveflume" or "front = wlevel" (if you are using a tide record too) on flow boundary conditions. Please check this topic. Note that, if I'm not wrong, the default value of this parameter is different depending on the version of your source code. Be sure of this on xbeach manual.

http://oss.deltares.nl/web/xbeach/forum/-/message_boards/view_message/1236630

hope this helps,

Guilherme

If It's a reflection problem, I had some issues with this too a time ago. Try to set "front = waveflume" or "front = wlevel" (if you are using a tide record too) on flow boundary conditions. Please check this topic. Note that, if I'm not wrong, the default value of this parameter is different depending on the version of your source code. Be sure of this on xbeach manual.

http://oss.deltares.nl/web/xbeach/forum/-/message_boards/view_message/1236630

hope this helps,

Guilherme

CT

##### Christophe Troch, modified 1 Year ago.

#### RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo

Capillary Posts: 2 Join Date: 2/9/17 Recent Posts
00

Please sign in to flag this as inappropriate.

Hi Guilherme,

Thanks for your reply, I actually came across your post about the reflection a while back. The reflection in my model did not seem to be the problem, although it does have an effect. I changed the offshore boundary to front = nonh_1D, and everything seems to work now, I do find the name a bit confusing, since I am running a 2D model of a coastline(The flume was just a simple example for illustration of the problem). None of the other offshore boundaries seem to generate the desired waves in the non-hydrostatic mode.

Thanks again for your reply.

Kind Regards,

Chris

Thanks for your reply, I actually came across your post about the reflection a while back. The reflection in my model did not seem to be the problem, although it does have an effect. I changed the offshore boundary to front = nonh_1D, and everything seems to work now, I do find the name a bit confusing, since I am running a 2D model of a coastline(The flume was just a simple example for illustration of the problem). None of the other offshore boundaries seem to generate the desired waves in the non-hydrostatic mode.

Thanks again for your reply.

Kind Regards,

Chris

NK

##### Nikos Kalligeris, modified 5 Months ago.

#### RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo

Capillary Posts: 2 Join Date: 11/18/17 Recent Posts
00

Please sign in to flag this as inappropriate.

Dear Xbeach users (my first post here),

I've come across a similar problem to the one discussed in this thread: I cannot match the input Hm0 at my model boundary.

I was comparing Xbeach overtopping predictions to a Boussinesq code, when I noticed that the output Hm0 in Xbeach is significantly enhanced compared to the input Hm0.

To investigate this further, I setup a constant depth test case:

- Model: 1D non-hydrostatic

- Bathy: 20m constant depth

- Wave BC: Jonswap spectrum with Tp=11s, Hm0=1.5m, gammajsp=3.3, s=38.6

- BC: front = nonh_1d, back = abs_1d, right = neumann, left = neumann

Note that the offshore boundary depth is within the green area as recommended in Figure 4.3 of the Xbeach-G manual.

In the figures attached here I'm showing:

i) The free surface elevation time-series (zs) at the boundary in comparison to the .bcf time-series. You can see that surface elevation is amplified in the model output compared to the random-phased time-series generated by the model.

ii) The spectral analysis of the two aforementioned time-series in comparison to the Jonswap spectrum (using the given parameters). The significant wave height of the model output is Hm0=1.69m instead of Hm0=1.5m.

Can anyone help me understand why this is happening? Does the directional spreading factor (s) have anything to do with this?

Thank you in advance.

Kind regards,

Nikos

I've come across a similar problem to the one discussed in this thread: I cannot match the input Hm0 at my model boundary.

I was comparing Xbeach overtopping predictions to a Boussinesq code, when I noticed that the output Hm0 in Xbeach is significantly enhanced compared to the input Hm0.

To investigate this further, I setup a constant depth test case:

- Model: 1D non-hydrostatic

- Bathy: 20m constant depth

- Wave BC: Jonswap spectrum with Tp=11s, Hm0=1.5m, gammajsp=3.3, s=38.6

- BC: front = nonh_1d, back = abs_1d, right = neumann, left = neumann

Note that the offshore boundary depth is within the green area as recommended in Figure 4.3 of the Xbeach-G manual.

In the figures attached here I'm showing:

i) The free surface elevation time-series (zs) at the boundary in comparison to the .bcf time-series. You can see that surface elevation is amplified in the model output compared to the random-phased time-series generated by the model.

ii) The spectral analysis of the two aforementioned time-series in comparison to the Jonswap spectrum (using the given parameters). The significant wave height of the model output is Hm0=1.69m instead of Hm0=1.5m.

Can anyone help me understand why this is happening? Does the directional spreading factor (s) have anything to do with this?

Thank you in advance.

Kind regards,

Nikos

KN

##### Kees Nederhoff, modified 4 Months ago.

#### RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo

Wind Posts: 41 Join Date: 3/3/14 Recent Posts
00

Please sign in to flag this as inappropriate.

Hi Nikos,

I am not sure what is going wrong with your model. It could, for example, be the reflection from the back boundary. Have you tried to filter the ingoing and outgoing waves in order to determine of this is the case? If you add you model setup I can have a look.

Cheers, Kees

I am not sure what is going wrong with your model. It could, for example, be the reflection from the back boundary. Have you tried to filter the ingoing and outgoing waves in order to determine of this is the case? If you add you model setup I can have a look.

Cheers, Kees

NK

##### Nikos Kalligeris, modified 4 Months ago.

#### RE: Hm0 output larger than Jonswap input at boundary for Non Hydrostatic mo

Capillary Posts: 2 Join Date: 11/18/17 Recent Posts
00

Please sign in to flag this as inappropriate.

Dear Kees,

Thank you for your response!

The test case was ran on a constant depth grid with front BCs set to nonh_1d and back BCs set to abs_1d.

Therefore I don't anticipate the increase in wave energy to be due to boundary reflections (especially since the phasing matches the BC random time series).

But now that you mention it, I'm getting a weird waning "automatically changing front to abs_1d with wavemodel = stationary" even though I define nonh=1.

Looking at the source code in params.F90, line 2001-2006, the code automatically assigns abs_1d to the front BCs of non-hydrostatic models:

! is using wavemodel = stat without front = abs_1d

if (par%front/=FRONT_ABS_1D) then

if (par%wavemodel == WAVEMODEL_NONH) then

call writelog('lws','','Warning: automatically changing front to abs_1d with wavemodel = stationary')

par%front = FRONT_ABS_1D

endif

endif

The code I'm running is the latest release (XBeach X Beta, version 1.23.5393M), compiled on a Linux server.

Earlier XBeach releases compiled on the same server (with intel fortran) had no such BC issues.

After my post, I downloaded the pre-complied Windows executable for the same release (XBeach X Beta), and again there were no amplification issues at the boundary.

I have therefore concluded that either a compiling error or bug must be causing this.

Nikos

Thank you for your response!

The test case was ran on a constant depth grid with front BCs set to nonh_1d and back BCs set to abs_1d.

Therefore I don't anticipate the increase in wave energy to be due to boundary reflections (especially since the phasing matches the BC random time series).

But now that you mention it, I'm getting a weird waning "automatically changing front to abs_1d with wavemodel = stationary" even though I define nonh=1.

Looking at the source code in params.F90, line 2001-2006, the code automatically assigns abs_1d to the front BCs of non-hydrostatic models:

! is using wavemodel = stat without front = abs_1d

if (par%front/=FRONT_ABS_1D) then

if (par%wavemodel == WAVEMODEL_NONH) then

call writelog('lws','','Warning: automatically changing front to abs_1d with wavemodel = stationary')

par%front = FRONT_ABS_1D

endif

endif

The code I'm running is the latest release (XBeach X Beta, version 1.23.5393M), compiled on a Linux server.

Earlier XBeach releases compiled on the same server (with intel fortran) had no such BC issues.

After my post, I downloaded the pre-complied Windows executable for the same release (XBeach X Beta), and again there were no amplification issues at the boundary.

I have therefore concluded that either a compiling error or bug must be causing this.

Nikos