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

Bounds Check Bug in WAMIT2 Submodule of HydroDyn #9

Closed
jjonkman opened this issue Mar 3, 2017 · 3 comments
Closed

Bounds Check Bug in WAMIT2 Submodule of HydroDyn #9

jjonkman opened this issue Mar 3, 2017 · 3 comments

Comments

@jjonkman
Copy link
Collaborator

jjonkman commented Mar 3, 2017

The upper bound on WaveDir is checked incorrectly in the WAMIT2 submodule of HydroDyn. See the following forum topic for details: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=1670.

The second problem reported in that forum topic is not a bug; the direction pairs must be fully populated (not sparse).

ashesh2512 pushed a commit to ashesh2512/openfast that referenced this issue May 21, 2018
Building on incorporating ExtLoads to the Fast flow framework
@karchramboll
Copy link

I have problems with calculating 2nd order wave forces on the basis of WAMIT output files .8 or .9. I tried the possible options (MnDrift=8 or 9, or NewmanApp=8 or 9) bot an error is caused by WAMIT2.f90 stating "Maximum wave direction required of [...] is found in the WAMIT data file...

Is there a working example available including WAMIT files, so I can check the input format? I am using WAMIT v6.4. The mean drift forces in files 8 and 9 are calculated using IOPTN(8)=2 and IOPTN(9)=2.

@jjonkman
Copy link
Collaborator Author

Unfortunately, the bug reported in the forum topic listed above has not yet been fixed by a pull request. And I don't have a HydroDyn example where the mean-drift loads are calculated from WAMIT *.8 or *.9 output files. While I thought these features were tested before they were released in HydroDyn, I don't have them in my records and those who did the implementation are no longer at NREL. Perhaps another OpenFAST user/developer can comment.

Have you tried to implement the code change suggested in the forum topic listed above; if so, did that help?

@andrew-platt
Copy link
Collaborator

After reviewing the forum posting and checking the code, I can confirm this is a bug. This has been fixed in commit b736f5b in the TCF development work, and will be merged into the dev branch with that code.

andrew-platt referenced this issue in andrew-platt/openfast Mar 19, 2020
andrew-platt pushed a commit that referenced this issue Jul 31, 2020
Updates to fix issues noted.  Also update reg tests
mattEhall referenced this issue in mattEhall/openfast Dec 3, 2020
added IF NOT ALLOCATED statement in awae.f90
@Master-PLC Master-PLC mentioned this issue Oct 9, 2021
andrew-platt pushed a commit that referenced this issue May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants