Water levels time update issue #816
Assignees
Labels
bug
Something isn't working
Comments
This was referenced Apr 24, 2023
Closed
MatthewMasarik-NOAA
added a commit
to MatthewMasarik-NOAA/WW3
that referenced
this issue
Jun 27, 2023
* origin/develop: handle NaN air-sea temperatures from nearest land points (NOAA-EMC#869) Increase valid_max for f in ounp (NOAA-EMC#1014) Bugfix deallocation of invalid memory in ww3_prnc (NOAA-EMC#1016) Update to orion intel module path and two typo corrections. (NOAA-EMC#1011) Bugfix to out of bounds array write in w3profsmd_pdlib.f90 (NOAA-EMC#1013) Simple logic fix for time interpolation of boundary nodes at the end of W3XYPFSNIMP. (NOAA-EMC#1005) in w3iors use NSEA instead of NSEAL in serial write/read of VA (NOAA-EMC#954) Update documentation for UNST namelist (NOAA-EMC#986) In certain coupled configurations, the piece of code testing the coupling frequency to check if 'receive' coupling exchanges need to take place fail, resulting in an infinite loop causing the integration between time zero and the first time step to repeat indefinitely. This check needs to be rewritten, which fixes also issue NOAA-EMC#816 in a simpler way. (NOAA-EMC#999)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The bug was discovered in a configuration having wind coupling and water levels read from file. In the ww3_shel program there is a call to the W3WAVE routine, and the time parameter of this routine specifying until what time we have to integrate is set after reading the different input fields in sequence.
Water levels are read before winds. This field is read from a file, and it is not interpolated. Therefore, the 'ending time' for W3WAVE is set to the initial time of the run. After this, winds are read, and the 'ending time' for W3WAVE should be updated to be the next coupling time step. The problem is that this 'ending time' is different to the ending time set by the water levels and the difference is negative (DTTST<0 in the ww3_shel program), so the result is that W3WAVE is called with and 'ending time' equal to the initial time of the run. Within this W3WAVE routine, the OASIS put/get routines are called, and nothing is done because the run time is not equal to the coupling time, which causes an inconsistency with the rest of the models WWIII is coupled to, leading OASIS to crash.
In conclusion, the error happens because the driving data is read twice in the first time step. Therefore, the oasis get routines are called twice for the first time step, which causes an error in OASIS as they should only be called once.
One possible solution would be interpolating the water levels by default, but this greatly increases the computation time because the grid has to be transformed each time step. Another solution would be not updating the 'ending time' for W3WAVE for the non-interpolated fields, but in this case an interpolated field must always be used when running WWIII (which does not seem unreasonable to me).
I managed to make this configuration work by initializing TFN(1) to zero instead of -1 in w3idatmd.ftn, but as there are various checks in the code for TFN(1) = -1 I am not sure this is a prudent thing to do. The rest of the changes I tried to make it work were unsuccessful.
To Reproduce
Run a configuration using water levels read from file, and winds or momentum as coupled field.
Expected behavior
OASIS will crash because the order in which the coupling fields are exchanged is not right.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: