Use temporary mesh for HD low-pass filter initialization

[andrew-platt]

NOT Ready to merge. This needs reworking.

Feature or improvement description
The ED%y%PlatformPtMesh was being directly altered during HD init to set the low pass filter history stored in discrete states. Changing an output of a module outside of the CalcOutput call within a module is generally not a great idea. It can lead to unintended consequences downstream -- such as in VTK writing, or if another module needs that info before it is recalculated.

So instead a temporary mesh is used.

Related issue, if one exists
This issue occurred #2341 (https://github.com/OpenFAST/openfast/pull/2341/files#diff-4a8a64358b038dd979f41ea2dd88c0e588a85d068560c0c1b42f98ae5d453452R1563)

Impacted areas of the software
Glue code, and maybe VTK outputs

Test results, if applicable
No results change with this

[andrew-platt]

After further discussion with @luwang00, there is a problem with this that needs to be addressed. The logic currently assumes that there is a mesh mapping from ED%y%PlatformMesh to HD%u%<meshes>. However, this mapping does not exist if SubDyn is used.

I propose we use a temporary mesh mapping from ED to HD for initializing this (the SD%y%Y2Mesh is rigid body motion, so this temporary mapping would be correct for init).

[bjonkman]

I'm trying to understand what this code is doing. From my initial look, it seems like this work could be happening inside ED_Init and HD_Init:

1. ED initial output translation displacements are getting modified based on ED InitOutput data
2. HD initial input guess is getting modified based on the modified ED initial output, and
3. HD states are getting modified based on the changed initial HD Input

I would think we could send HD_Init the information from the mesh and do these calculations inside HD_Init (this would also remove some duplication in the HD driver). It's quite likely I'm missing something to explain why it was done this way.

However, with the code change here, I don't think it will give the same results as before:

1. ED%y isn't modified (a temp mesh is modified, but not actually used elsewhere);
2. HD%Input(1) isn't getting modified (it's commented out in line 1690); and
3. HD%xd is not using the expected values of HD%Input(1) below (e.g. line 1699) because of item 2

[andrew-platt]

I made a temporary commit late on Friday with notes on things I thought need to be done. A few things were deleted during that commit as @luwang00 and I were figuring out the issue we had. So what is here is an in between broken state of code.

Basically what should be happening here is the setting of some state information for the low pass yaw filter (I suspect it needs to be only close enough, but not exct). I don't think we actually want to change the ED%y at all.

I like the suggestion of handling this inside the HD_Init routine. That would certainly be cleaner at the glue code level, and likely will work better with tight coupling.

[luwang00]

Hi @andrew-platt and @bjonkman, thanks for the comments and discussions and sorry for the delay on this. I think my initial plan of using mesh mapping to compute the initial potential-flow body positions is making things more complicated than it needs to be. I also like the plan of moving the initialization calculation out of the glue-code and into HydroDyn_Init.

Following your suggestions, I reimplemented the initialization here luwang00@be8a671. It's working correctly based on my tests. This updated implementation should fix several issues:

• ED%y is no longer modified.
• It does not rely on mesh mapping, so it works with ED+HD and ED+SD+HD (tested).
• SmllRotTrans is replaced with EulerConstructZYX to support large platform rotation.

Please let me know if you see any problems with this new implementation. If it checks out, we can update this pull request with luwang00@be8a671. Not sure what's the best way to do this. @andrew-platt, can you help with this? Thanks!

[andrew-platt]

@luwang00, could you make a PR from your branch to dev? I'll go ahead and close this PR since yours is a much better solution.

[luwang00]

Thanks @andrew-platt. Will do.

[andrew-platt]

closing in preference of better solution in #2444