Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with ST4 SDSBCHOICE=2 #1074

Open
benoitp-cmc opened this issue Sep 15, 2023 · 9 comments
Open

Problem with ST4 SDSBCHOICE=2 #1074

benoitp-cmc opened this issue Sep 15, 2023 · 9 comments
Labels
bug Something isn't working

Comments

@benoitp-cmc
Copy link
Contributor

benoitp-cmc commented Sep 15, 2023

Describe the bug
I have a Great Lakes case where I run with T500. It used to produce a reasonnable wave forecast, following #189 the forecast is much slower (more than 6 times) and produces Hs up to 125 m.

To Reproduce
Try a run with T500 parameters

  • Before 189: SDSC1=1, SDSBCK=0.185, etc.
  • After 189: SDSBCHOICE=2, SDSBCK=0.185, etc.

Expected behavior
Same behaviour as before #189. Not 125 m wave heights.

Additional context

  • With T500 (SDSC1=1, SDSBCK=0.185), the T441/Ardhuin et al. if would be true and so would be the T500/Filipot et al. if. The second if depends on the PB value defined in the first if.
  • The second to last line of T500/Filipot et al PB = (1-SSDSC(1))*PB2*A + SSDSC(1)*PB no longer works now that SDSBCHOICE uses SSDSC(1) and must be 2 in this context rather than a namelist option (1 for T500).
  • tp1.8. is the only regression test for SDSBCHOICE=2. It only runs for a minute and no wind input which is probably why it gave sensible results.

/cc @mickaelaccensi

@benoitp-cmc benoitp-cmc added the bug Something isn't working label Sep 15, 2023
@benoitp-cmc benoitp-cmc changed the title Problem with ST4 SDBCHOICE=2 Problem with ST4 SDSBCHOICE=2 Sep 15, 2023
@mickaelaccensi
Copy link
Collaborator

Hi Benoit,
Can you try with this branch:
https://github.com/umr-lops/WW3/tree/feature/ST4table

If the issue is still here, I'll see with Fabrice to add a bugfix in this branch

Mickael

@benoitp-cmc
Copy link
Contributor Author

It did not compile (Intel).

.../model/src/w3gdatmd.F90(2639): error #6460: This is not a component name that is defined in the encompassing structure.   [SINTAILPAR]
    SINTAILPAR  => MPARS(IMOD)%SRCPS%SINTAILPAR
-------------------------------------^
.../model/src/w3gdatmd.F90(2639): error #6794: The rank of the target is different from the pointer.   [SINTAILPAR]
    SINTAILPAR  => MPARS(IMOD)%SRCPS%SINTAILPAR
----^
.../model/src/w3gdatmd.F90(2639): error #6795: The target must be of the same type and kind type parameters as the pointer.   [SINTAILPAR]
    SINTAILPAR  => MPARS(IMOD)%SRCPS%SINTAILPAR
----^

I don't understand all the changes in this branch but it doesn't look like they would adress the first two bullets I mention in "Additional context".

@benoitp-cmc
Copy link
Contributor Author

What I think is needed is changes similar to this:
https://github.com/eccc-waves/WW3/tree/bugfix/sdsbchoice2

With this branch, I no longer get 120 m Hs. But it's not right yet, I get Hs that are ~40% higher than with the old T500.

@ardhuin
Copy link
Contributor

ardhuin commented Sep 18, 2023

Hello ...I'll have to check a few things on what I've changed that could affect the tail of the spectrum. It almost sounds like dissipation is zero...
It is easy to use ts1.1 to check for these kind of things.
thanks for spotting this issue.

@benoitp-cmc
Copy link
Contributor Author

benoitp-cmc commented Sep 19, 2023

Merci d'y jeter un coup d'oeil.

With SSDSC(1)=2 and PB=0, the calculation of PB = (1-SSDSC(1))*PB2*A + SSDSC(1)*PB, likely gives a negative probability of breaking.

Once the wind starts, the energy accumulates very rapidly with only episodical dissipation until Hs reaches a fixed height. The pattern of max Hs seems to match bathymetry pretty closely, up to a point.

Signficant wave height (m) after 24 hours from cold start (similar to 6 hours except in some isolated corners)

rewps_hs_sdsbchoice2

Bathymetry (m)

rewps_bathymetry

@ardhuin
Copy link
Contributor

ardhuin commented Oct 2, 2023

OK, there was one line missing in the code, and the dissipation was effectively zero.
basically in w3src4md.F90 we need to have
SRHS = DDIAG * A
just before
!
CASE(3)
I've just added this and an option in ww3_ts1 to test this T500 setting (this is in a local ST4 branch). Mickael should be pushing this through shortly.

mickaelaccensi added a commit to umr-lops/WW3 that referenced this issue Oct 3, 2023
address issue NOAA-EMC#1074
add regtest
@benoitp-cmc
Copy link
Contributor Author

I will test next week.

@benoitp-cmc
Copy link
Contributor Author

Adding SRHS = DDIAG * A helped. On its own the result is still pretty far (~50% too high). Along with a476ee8 and d73e295 the results are pretty close but still about 10% higher than before #189. I'll try ww3_ts1.

@ardhuin
Copy link
Contributor

ardhuin commented Oct 11, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants