Adding DVGeometryMulti to MPhys

[bernardopacini]

Purpose

Adding DVGeometryMulti to MPhys. I added pass-through functions and modified the compute and compute_jacvec_product calls as needed.

Expected time until merged

1 week.

Type of change

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

Testing

I tried this on my optimization and it appears to work (local analysis and derivatives on HPC). I would appreciate others verifying this on their cases.

Checklist

• 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
• 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
• I have added necessary documentation

[codecov]

Codecov Report

Attention: 72 lines in your changes are missing coverage. Please review.

Comparison is base (e47a454) 65.04% compared to head (a383525) 64.83%.

Files	Patch %	Lines
pygeo/mphys/mphys_dvgeo.py	0.00%	72 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #230      +/-   ##
==========================================
- Coverage   65.04%   64.83%   -0.21%     
==========================================
  Files          47       47              
  Lines       12112    12150      +38     
==========================================
  Hits         7878     7878              
- Misses       4234     4272      +38     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bernardopacini]

I didn't add the addIntersection() method to the MPhys wrapper. Let me know if you think it should be here or if it should be left as a direct reference to the underlying class.

[bernardopacini]

Additional note: when adding a global DV the input was being added twice to OpenMDAO. This bug is fixed here too.

[bernardopacini]

It turns out PR #201 broke the naming convention for child FFDs by prepending the child name by default. This meant that MPhys would not connect the OM variable to the DVGeo variable because the names would not match. I fixed that in this PR by setting prependName=False for all FFD-based design variables.

[sseraj]

Looks pretty good. I just have a few minor comments

[anilyil]

Most of this look good, but one big picture comment: it looks like the logical check to find the correct dvgeo is repeated in several places. Instead, I think you can reduce duplication by using "nom_getDVGeo" before each DV addition. That way you wont need to duplicate the code that finds the right DVGeo. Is this correct? If you also think this makes sense, I say go for it. If not, I am fine with merging as is.

[hajdik]

LGTM, just a few comments

[hajdik]

Can you add a docstring for this function since you added it??

[hajdik]

I agree with Anil on using this to cover finding the right DVGeo even with the child/component logic instead of repeating the same checks. I think I just didn't realize it could eliminate the checks for child that I put in when I redid the DV adding functions.

[bernardopacini]

There is some weird behavior in the derivatives: the first check totals is fine, but a second check totals after a design perturbation makes the second function derivative wrong. This only happens when there is an intersection. I can't exclude this being an issue with DAFoam (or even IDwarp), but I do not have the bandwidth to look more into this now. Converting to a draft.