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

Bug Fix: Fixing issue that MoorDyn writes positions and tensions of t… #604

Merged

Conversation

pschuenemann
Copy link
Contributor

…he wrong node to OpenFAST's output file

Feature or improvement description

MoorDyn features two different methods of generating output:

  1. Using flags in the Line Properties section of the MoorDyn input file. This generates a line output file <rootname>.MD.Line#.out for each flagged line.
  2. Using a OpenFAST like output list in the output section of the MoorDyn input file. This generates a main MoorDyn output file <rootname>.MD.out and writes to the OpenFAST output file <rootname>.out.

Both methods can be used to output the same physical quantities.

In general this works well, however when I analysed the outputs of some OpenFAST simulations using MoorDyn, I realized that the values of the same output parameters are not consistent between the different output files. To be more precise the values in the *.MD.out and the *.out file are the same, but those are differing from the values in the line output files (*.MD.Line#.out).
After comparing the different output files, I assume that the output of *.MD.Line#.out is the correct one and that there is a problem with the values written to the main MoorDyn and OpenFAST output file.
Doing the comparison, I realized that if one requests to write the position or the tension of an arbitrary node @ of line # using the prefix L#N@ to the OpenFAST output file, in the *.MD.out and the *.out file always the position/tension of the last node of the requested line was written and not the position/tension of the requested node @.

The proposed change of the source code in this pull request should fix this wrong behaviour. It just changes one line and is most likely just a correction of a typo in the source code.

Related issue, if one exists

No issue related. (I thought, it would be not really necessary to open up a new issue for this minor change. Please let me know, if I am wrong.)

Impacted areas of the software

MoorDyn

Additional supporting information

Note, applying this bug fix will write the correct node positions to the OpenFAST output file. However, for the tension of a requested node the tension of the segment preceding to the requested node will be output. For example, if one requests the output of L1N10Ten, then the tension at segment 10 (Seg10Ten) which to my understanding connects node 9 and 10, will be written. This leads to zero tension to be written for L#N0Ten!!!
I am not shure, if that is the expected behaviour. Especially, the zero tension for the first node seems a bit weird to me. What do you think on this @mattEhall?

Test results, if applicable

Actually, I cannot add test results here, as my regression tests are all failing with an error saying:

FAST_InitializeAll:Error allocating IfW%Input and IfW%InputTimes. 
forrtl: severe (153): allocatable array or pointer is not allocated 

However, I don't think that this is related to this pull request, because I get the same error when running the regression tests on the current (original) OpenFAST dev branch.

@andrew-platt
Copy link
Collaborator

andrew-platt commented Nov 29, 2020

@mattEhall, can you review and comment?

@mattEhall
Copy link
Contributor

This is an accurate correction of a bug/typo in the code. The MoorDyn v2 code under development doesn't have this problem, but until that is ready it is worth incorporating this correction.

Paul, thank you for sharing this bug and your correction.

Regarding the weird-seeming behavior of the tension outputs:

  • The static tension, dynamic (damping-related) tension, strain, and strain rate outputs in the line-specific output files are intended to be for each segment (as opposed to each node) of the line, as you observed.
  • I agree that the current implementation of tension outputs in the main output file (e.g. L1N4Ten) is awkward.
  • My plan for these custom tension outputs (e.g. L1N4Ten) is that they be for a specific node (rather than segment). This change has some subtle advantages in matching true fairlead tensions including inertial loads of the end segment, and it should also address the odd behavior you noted when entering L#N0Ten. It will be done in the upcoming version 2.

@pschuenemann
Copy link
Contributor Author

pschuenemann commented Nov 30, 2020

Hi @mattEhall, Hi @andrew-platt ,

thank you very much for your positive feedback and your recommendation for incorporating the change in the next release of OpenFAST.

Nice to hear, that there is a new version of MoorDyn under development. Could you already foresee when it will be available?

However for now, I am still struggling a bit with the tension outputs of the current MoorDyn version and what they mean. Thus, I open up a new topic in the NREL forum at https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=2606, as I think it is more suitable to clarify it there then here. Any help on this is highly appreciated, so that I get the correct interpretation of simulation results until v2 is available.

@andrew-platt: If there is anything else I can do so that you can incorporate my bug fix in the official OpenFAST code, please let me know.

Cheers Paul

@mattEhall
Copy link
Contributor

Hi @pschuenemann - Early working versions of MoorDyn v2 in OpenFAST will likely be available on GitHub in early January, though it may take more time before the update is reflected in a vetted OpenFAST release. I've replied to your query in the forum.

@pschuenemann
Copy link
Contributor Author

Thanks @mattEhall, @andrew-platt and @rafmudaf for your quick replies, support and the merge. It's great!

@rafmudaf rafmudaf mentioned this pull request Jan 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants