Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVD composite DVs for VSP and ESP #170

Merged
merged 35 commits into from
Jan 23, 2023
Merged

SVD composite DVs for VSP and ESP #170

merged 35 commits into from
Jan 23, 2023

Conversation

ArshSaja
Copy link
Contributor

@ArshSaja ArshSaja commented Jan 3, 2023

Purpose

Expected time until merged

This PR includes the @nwu63 composite DV concept of FFD cases. A similar formulation is implemented to use the SVD transformation for VSP and ESP design variables. A test for VSP is also included.

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

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

@ArshSaja ArshSaja requested review from ewu63 and hajdik January 3, 2023 23:03
@ArshSaja ArshSaja requested a review from a team as a code owner January 3, 2023 23:03
@ArshSaja ArshSaja requested a review from anilyil January 3, 2023 23:03
@codecov
Copy link

codecov bot commented Jan 3, 2023

Codecov Report

Merging #170 (e3916c9) into main (4ac53e0) will decrease coverage by 0.36%.
The diff coverage is 61.02%.

@@            Coverage Diff             @@
##             main     #170      +/-   ##
==========================================
- Coverage   64.14%   63.78%   -0.36%     
==========================================
  Files          47       47              
  Lines       11866    11954      +88     
==========================================
+ Hits         7611     7625      +14     
- Misses       4255     4329      +74     
Impacted Files Coverage Δ
pygeo/mphys/mphys_dvgeo.py 0.00% <0.00%> (ø)
pygeo/parameterization/BaseDVGeo.py 66.66% <61.53%> (-3.34%) ⬇️
pygeo/parameterization/DVGeoSketch.py 68.22% <64.17%> (-1.55%) ⬇️
pygeo/parameterization/DVGeoESP.py 66.29% <91.66%> (+1.41%) ⬆️
pygeo/parameterization/DVGeoVSP.py 81.54% <92.30%> (+0.11%) ⬆️
pygeo/parameterization/DVGeo.py 68.63% <100.00%> (+2.23%) ⬆️
pygeo/constraints/areaConstraint.py 50.50% <0.00%> (-25.42%) ⬇️
pygeo/constraints/DVCon.py 68.48% <0.00%> (-3.25%) ⬇️
pygeo/parameterization/designVars.py 79.25% <0.00%> (+1.59%) ⬆️
... and 1 more

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

Copy link
Contributor

@hajdik hajdik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice, great that the SVD DVs can be used for other parameterizations now! I have some (primarily formatting) comments to start.

pygeo/mphys/mphys_dvgeo.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeo.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeo.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeoESP.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeoESP.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeoSketch.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeoSketch.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeoSketch.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeoSketch.py Outdated Show resolved Hide resolved
pygeo/parameterization/DVGeoSketch.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@ewu63 ewu63 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add a test for the FFD stuff, and make sure the refactoring does not change the behaviour of that code.

@ArshSaja
Copy link
Contributor Author

Why was this argument added? It looks like s gets set to none in one case and returned from a function in the other case so the argument is always overwritten @hajdik

Right! the option was not necessary, it was removed.

@hajdik
Copy link
Contributor

hajdik commented Jan 11, 2023

When the composite DVs are added to openmdao, the default VSP DVs are DVs anymore. Therefore, we don't have output for these DVs. If the VSP DVs are added as inputs, OpenMDAO will consider them as DVs.

So does this not happen for other composite DVs when used in MPhys?

@ArshSaja
Copy link
Contributor Author

When the composite DVs are added to openmdao, the default VSP DVs are DVs anymore. Therefore, we don't have output for these DVs. If the VSP DVs are added as inputs, OpenMDAO will consider them as DVs.

So does this not happen for other composite DVs when used in MPhys?

This is the same for all composite DV cases. The optimizer has the information on composite DVs only, it doesn't have the information on the default DVs from VSP. pyGeo does the transformation from composite to default DVs when the necessary changes are required inside it.

@hajdik
Copy link
Contributor

hajdik commented Jan 11, 2023

This is the same for all composite DV cases. The optimizer has the information on composite DVs only, it doesn't have the information on the default DVs from VSP. pyGeo does the transformation from composite to default DVs when the necessary changes are required inside it.

If it would be the same for all composite DVs, shouldn't the if add_input statement be added to all of the nom_add functions so that MPhys will work with all DVGeos and composite DVs? Also, could you add a comment explaining why the if statement is there to the code so it is more clear?

@ArshSaja
Copy link
Contributor Author

This is the same for all composite DV cases. The optimizer has the information on composite DVs only, it doesn't have the information on the default DVs from VSP. pyGeo does the transformation from composite to default DVs when the necessary changes are required inside it.

If it would be the same for all composite DVs, shouldn't the if add_input statement be added to all of the nom_add functions so that MPhys will work with all DVGeos and composite DVs? Also, could you add a comment explaining why the if statement is there to the code so it is more clear?

Added the composite optionality to all DVGeo.

hajdik
hajdik previously approved these changes Jan 11, 2023
# global DVs are only added to FFD-based DVGeo objects
if self.geo_type != "ffd":
raise RuntimeError(f"Only FFD-based DVGeo objects can use global DVs, not type:{self.geo_type}")

# define the input
self.add_input(dvName, distributed=False, shape=len(value))
# When composite DVs are used, input is not required for the default DVs
if add_input:
Copy link
Contributor

@hajdik hajdik Jan 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think that the reason this step happens is unclear when you just read the code and don't have the context of the PR. Because add_input is used IFF the DV is composite (correct me if I'm wrong), I think it would make more sense to have the variable name reflect that. Like if the variable name were isComposite or something similar so the check becomes
if isComposite(): <do thing>
and then the comment can say that the initial setup of the composite DV makes the extra step necessary.

@ArshSaja
Copy link
Contributor Author

The add_input is not required when we use composite DVs. so if isComposite is false by default, the input has to be added to the OpenMDAO. If isComposite is true, then we don't need to add the inputs. Now the name convention should be fine.

@ewu63
Copy link
Collaborator

ewu63 commented Jan 21, 2023

Have we verified that the FFD DVGeo SVD tests also pass on the main branch before the PR?

@ArshSaja
Copy link
Contributor Author

Yes I tested the same test with main branch. It was working.

Copy link
Collaborator

@ewu63 ewu63 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have time to review this PR in detail, it would be good if someone else can take a look.

@ewu63 ewu63 requested review from ewu63 and removed request for ewu63 January 21, 2023 19:07
@ewu63 ewu63 requested review from ewu63 and removed request for ewu63 January 21, 2023 19:09
@hajdik hajdik merged commit 0e67ef4 into mdolab:main Jan 23, 2023
@sseraj sseraj mentioned this pull request Jan 24, 2023
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants