Linearization with AD15 and IfW

[andrew-platt]

This is not ready for merging.

Feature or improvement description When InflowWind was converted to use pointers, significant changes were required to AeroDyn to support this with linearization (InflowWind outputs are no longer inputs to AeroDyn). This is the second of 3 PR's to address this.

Related issue, if one exists PR #1882 is the PR in the sequence.

Impacted areas of the software

Linearization in the following modules is affected:

• AeroDyn
• InflowWind
• glue code

Additional supporting information

Test results, if applicable

• The following regression tests have changed:
• Fake5MW_AeroLin_B1_UA4_DBEMT3 - Does not reproduce correct results yet.
• Fake5MW_AeroLin_B3_UA6 - Does not reproduce correct results yet.
• Ideal_Beam_Fixed_Free_Linear - Reproduces results, but does fails due to change in matrix sizes
• Ideal_Beam_Free_Free_Linear - Reproduces results, but fails due to change in matrix sizes

---

Note: This branch will be rebased soon to resolve conflicts and simplify comparisons.

[bjonkman]

Could you share the documentation on these linearization updates? I see that AeroDyn has more meshes, different fields on those meshes, and reordered some of the meshes in its linearization matrices. I am going to need that if/when I implement those changes to couple with other modules. I was hoping any new meshes would go at the end of the list of existing AeroDyn inputs so that I wouldn't have to reorder anything, but it looks like that's not the case. @andrew-platt , @jjonkman

[andrew-platt]

Hi @bjonkman,

I ran into issues with just tacking the new meshes at the end. There were a few spots where the indexing counts the inputs backwards from the end of the u_AD arrays for getting the UserProp and extended inputs. Since that required inserting the new meshes ahead of this section, I simply moved them up to the top and reordered a bit. I'm not entirely positive all the ordering is correct and all cross terms are in yet, but I think I'm close. I do have a document with this info, but need to make a few updates with the dU_{AD}/du_{AD} cross terms (vel -> accel terms, etc). We'll share that with you when we get this finalized a bit.

For ElastoDyn, I was able to simply add new meshes at the end. In both AD and ED, some existing meshes have more fields that are getting used, so that modified indexing a bit. At present I still have something a bit off somewhere -- the Ideal_Beam and Fake_5MW linearization produce different frequencies than before, but the others all work.

It is also worth noting the @deslaughter is working on an an index managing system that he wants to include in the 4.0 release. We might need to discuss when that change should be included -- might make more sense to put it in 5.0 with the new tight coupling methods so that you have something easier to work with in 4.0.

Regards,

[bjonkman]

Thanks, Andy. I would appreciate it if the reordering you do on these meshes gets updated in Jason's LinearizationOfMeshMapping document since the code was originally written to follow that document. I will have to reorder things in our structural module to match your order.

[andrew-platt]

@bjonkman, that is the document I was referring to. :) It is now at rev 19b.

Regarding my earlier comment about a new indexing scheme that @deslaughter is working on: that scheme will be included in 5.0, not 4.0 as I stated above. The changes in this PR will be included in this v4.0.

[deslaughter]

I tried debugging the test failure in rtest-modules-drivers which comes from ad_B1n2_OLAF. I tracked it down to the use of u%V_wind in FVW_UpdateStates and FVW_CalcConstrStateResidual. Since V_wind isn't being populated, it is full of NaNs. I'm not sure what the fix is, but I thought this might be useful information.

[andrew-platt]

I tried debugging the test failure in rtest-modules-drivers which comes from ad_B1n2_OLAF. I tracked it down to the use of u%V_wind in FVW_UpdateStates and FVW_CalcConstrStateResidual. Since V_wind isn't being populated, it is full of NaNs. I'm not sure what the fix is, but I thought this might be useful information.

Good catch. Thanks for helping find the root cause! Corrected with commit b91e61e.

[andrew-platt]

See https://github.com/andrew-platt/openfast/pull/23 for a temporary PR for comparing what changes in this PR relative to #1882.