Local DVs are not consistent with in-plane section rotations

[marcomangano]

Description

pyGeo users should be aware of an inconsistency in the way local design variables are implemented.
Any time the full set of design variables is updated, pyGeo will first update the global design variables, then apply individual FFD displacements.
The problem stems from the fact that DVs added with addLocalDV can only be displaced along the global reference axes.

This implies that when local design variable displacements occur after a section has been twisted, shape variables will "ignore" this rotation and will just be displaced over the user-defined axis, eg."y".
Such an issue is barely noticeable for regular aircraft applications, where twist is limited to a few degrees, but if you for example have large pitch deformations + shape variables on a wind turbine model, this happens:

As I was digging through, I realized that addLocalSectionDV should be intended also for this purpose and not solely "winglet" handling, but switching to this different DV type did not change the behavior. I tested displacements along different axes to verify that the way I was calling the DV was correct, so I assume that addLocalSectionDV either:

• does not work with children FFD or
• ignores in-plane rotations of the FFD section

Even if LocalSectionDV gets fixed or extended to cover this case, I feel that having local DVs to follow the local section rotations should be the default behavior, instead of being enabled by an "exotic" DV.
I don't see any point in having the current behavior shown above as default!

Proposed fix

The order of DVs update should be changed, with local DVs going first and global DVs being updated at the last step.
The main challenge I see is that we need to update the links_x attributes of the refAxis (see sketch below) for this to work.

These vectors connect the intersection of the refAxis with the FFD section plane (whose coordinates are handled by user-implemented DVs by using extractCoef() and restoreCoef()). Any rotation or scaling operation relies on these links to appropriately update the control points location.
The logical steps for the updated code to work would be:

1. initialize the FFD object, including the refAxis and it's links to the FFD coefficients
2. apply shape DVs and re-compute all the links
3. apply global DVs using the updated links

I assume the original developers had a reason to implement geometry manipulation operations in this order, but I feel we should refactor at least this section of pyGeo as soon as possible.

Steps to reproduce issue

I have just tried this on my cases, but someone should also try this to replicate the issue

1. Take a simple 3D case - e.g. the MACH-Aero tutorial
2. set some very high twist value, and set a large displacement of one or two design variables
3. run an analysis and write the deformed DVs or use DemoDesignVars

Current behavior

See fist pic above

Expected behavior

Shape vars should be displaced perpendicularly to the "chord axis" of the rotated FFD section.

[marcomangano]

If I understood @anilyil offline comment correctly, one implementation reason to explain this ordering is that in DVGeo.update the links between the FFD control points and the reference axis nodes (links_s, links_n) are never re-computed after the FFD object is finalized, but only stretched and rotated by the global DVs. If we had to invert the order and have local vars applied first, these links would need to be recomputed (in a complex-safe manner) by calling again that code snippet in finalize after the local points are displaced and before any of the global variables are applied.

Once the DVs are applied and the FFDs are moved to the updated location, nothing should change as we update the embedded volumes and propagate the complex component to get the derivatives