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.