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

Fix bug that could cause incorrect loads transfer in Line2-to-Line2 or Line2-to-Point mapping #488

Merged
merged 1 commit into from
Jul 8, 2020

Conversation

bjonkman
Copy link
Contributor

@bjonkman bjonkman commented Jul 8, 2020

Complete this sentence
THIS PULL REQUEST IS READY TO MERGE

Feature or improvement description
This pull request fixes a problem identified in the implementation of the mesh mapping line2-to-line2 and line2-to-point loads-transfer algorithm. The algorithm to create the augmented source mesh would split an element but--in certain (fairly rare?) instances--incorrectly calculate the position of the new node, effectively increasing the load being transferred.

Related issue, if one exists
None

Impacted areas of the software
This may impact any modules that have distributed loads output. This includes any models that use

  • AeroDyn15 to transfer loads to ElastoDyn or BeamDyn, or
  • HydroDyn to transfer loads to SubDyn.

Additional supporting information
I have attached a plot showing a case where this bug was triggered. The red line shows the smooth loads expected from AeroDyn's output mesh; the blue line indicates how the loads input to the structural code were being calculated prior to this bug fix:
problem2

Test results, if applicable
The regression tests look the same (with the exception of the numerical instability in the SWRT case), indicating that this bug probably wasn't triggered in any of these test cases.

Line2-to-Line2 or Line2-to-Point load transfers in some instances could have created augmented meshes with nodes in incorrect places, and possibly cause incorrect loads transfer in the process.

Also fixed the mesh debugging code so that if a mesh has scalar quantities, it stores the number of scalars that it is writing to the binary file.
@jjonkman
Copy link
Collaborator

jjonkman commented Jul 8, 2020

I've discussed this previously unknown bug and fix with @bjonkman and approve this pull request.

@andrew-platt
Copy link
Collaborator

Good catch! I think I've seen this bug once with a BeamDyn test case, but thought it was just something odd with BeamDyn.

@andrew-platt andrew-platt merged commit d45d05e into OpenFAST:dev Jul 8, 2020
@bjonkman bjonkman deleted the bug/MeshMapping branch July 8, 2020 20:21
@rafmudaf rafmudaf mentioned this pull request Sep 11, 2020
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.

3 participants