DVGeoMulti anisotropy and loop efficiency

[sseraj]

Purpose

I added an "anisotropic" deformation option in DVGeoMulti. This is something I needed because my initial intersection curve was skewed. I do not expect this feature to be necessary for most cases.

While adding this feature, I also fixed some inefficiencies in the curve-based deformation loops. For update, I moved some computations out of the loop over points. For sens, I did the same thing and also switched the order of the loops to avoid unnecessary computations.

Lastly, I removed the outdated and unused update_d function.

Details on why I needed the anisotropy option

The figure below shows the wing-fuselage collar for my configuration. The initial wing-fuselage intersection curve is shown in orange and the intersection curve after design changes is shown in blue.

The initial intersection curve is "skewed" in that the trailing edge part of the intersection is very flat. This can be a problem because the inverse-distance warping used in DVGeoMulti is a point-based approach that does not account for surface connectivity. In my case, this was causing points on the lower surface near the trailing edge intersection to follow the trailing edge instead of the lower surface:

Using anisotropy=[0.3, 0.8, 1.0] increases the influence of parts of the curve on the same x-y plane as the points being warped. This fixes the issue and results in better mesh quality near the trailing edge:

Expected time until merged

1 week

Type of change

• [ ] Bugfix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (non-backwards-compatible fix or feature)
• [ ] Code style update (formatting, renaming)
• [x] Refactoring (no functional changes, no API changes)
• [ ] Documentation update
• [ ] Maintenance update
• [ ] Other (please describe)

Testing

I updated the DVGeoMulti test to use the anisotropy option. The original test passed with the default behavior (no anisotropy), which shows that the refactoring did not change the updated points. The new test proves that the derivatives work with the anisotropy change.

Checklist

• [x] I have run flake8 and black to make sure the Python code adheres to PEP-8 and is consistently formatted
• [ ] I have formatted the Fortran code with fprettify or C/C++ code with clang-format as applicable
• [x] I have run unit and regression tests which pass locally with my changes
• [ ] I have added new tests that prove my fix is effective or that my feature works
• [x] I have added necessary documentation

[codecov[bot]]

Codecov Report

Merging #167 (a6d250a) into main (b27c15a) will increase coverage by 0.12%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #167      +/-   ##
==========================================
+ Coverage   63.92%   64.05%   +0.12%     
==========================================
  Files          47       47              
  Lines       11818    11814       -4     
==========================================
+ Hits         7555     7567      +12     
+ Misses       4263     4247      -16     

Impacted Files	Coverage Δ
pygeo/parameterization/DVGeoMulti.py	91.00% <100.00%> (+1.23%)	:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[eirikurj]

@sseraj just to follow up from the "testing" section discussion during maintenance. Do you plan to add any tests for the new option?

[sseraj]

@sseraj just to follow up from the "testing" section discussion during maintenance. Do you plan to add any tests for the new option?

I can add a non-default anisotropy to the existing test and retrain. I could also parameterize the test so that is runs both with default and non-default values, but if the test passes with non-default values, that should also cover the default behavior (anisotropy=[1.0, 1.0, 1.0]). What do you think?

[sseraj]

@hajdik I added some figures and a more detailed explanation on why I needed the anisotropy option in the PR description