Triangulated surface constraint using geograd and multiple DVGeos per DVCon

[bbrelje]

Purpose

This PR adds the KS-based triangulated surface constraint from the Brelje et al AIAAJ paper

Type of change

What types of change is it?
Select the appropriate type(s) that describe this PR

• 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

Reg tests with good coverage have been added. All previous DVConstraints tests pass after the refactor.

Checklist

Put an x in the boxes that apply.

• I have run flake8 and black to make sure the code adheres to PEP-8 and is consistently formatted
• 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

[anilyil]

This looks good in general. One discussion; you are currently allowing multiple DVGeos kicking around with a single DVCon. I was doing this in a slightly different way with DVGeoMulti, where I had an upper-level dvgeo object, that kept track of all of the individual DVgeos for each component. that way we can also define intersections etc. I think we can come up with a common way to handle multiple dvgeos and use a consistent approach.

Here is what I recommend: I understand you don't want to make changes at this point. I also do not want to work on geometry stuff. BUT, I think we can come up with a much better scheme if we sit down together and do a mini hackathon with you. I am guessing we can take care of this work within a few hours on a call.

What do you say @bbrelje? If you don't want to make changes, that is totally fine by me and the PR is good as far as I am concerned.

[anilyil]

I talked to ben and we decided to merge this PR now, and we will refactor these stuff for harmony when we merge the dvgeomulti code. We estimate to do this in April, when ben will be done running the cases for his thesis work. I will create an issue about this and also move my dvgeomulti code to my public fork because the paper is accepted and in press now.

[anilyil]

I have created the issue that details the refactoring in #57.

[bbrelje]

I forgot I never included the triangulated volume constraint when I ported from the tensorflow-based geograd to the fortran one. I will need to deprecate that function or add it to geograd this weekend (probably the former). Block merge for now.

[anilyil]

@bbrelje I converted the PR to a draft. I understand you want to work on this more? I did the draft thing to prevent somebody accidentally merging this since both reviewers approved.

[ewu63]

geograd tests failed previously, this has now been fixed. I've verified locally that all tests pass, so I'll merge manually.