Fixed abs2prom and variable names to support OpenMDAO 3.39

[davidszt2]

With this PR OpenConcept works with OpenMDAO 3.39, but 3.40 is still not supported yet. Closes #74

---

@kanekosh As per issue #74 here is a work in progress for the OpenMDAO 3.39.0 compatibility issue.

I've put together a quick fix that is working for the minimal.py example. This is an attempt to reconstruct the _var_abs2prom attribute from _var_abs2meta (instead of choosing a completely new approach for automatic linkage).

This solution is very hacky and is failing the examples with user-defined integrators, but pushing this for the idea. Will keep working on this in my free time and let you know if I find any better/more robust solutions!

[A-CGray]

Hey @davidszt2, thanks for getting the ball rolling on this. Turns out the information that was in _var_abs2prom is now stored in _resolver._abs2prom. Annoyingly the promoted names in _resolver._abs2prom are stored in a tuple along with some other data so you can't access them in exactly the same way you would with _var_abs2prom. I wrote a little helper function to get the promoted name from whichever abs2prom dictionary is available and converted the code to use that.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.04%. Comparing base (806cb8b) to head (eb2734f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #76      +/-   ##
==========================================
- Coverage   82.06%   82.04%   -0.02%     
==========================================
  Files         103      103              
  Lines       10715    10724       +9     
==========================================
+ Hits         8793     8799       +6     
- Misses       1922     1925       +3     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[A-CGray]

I found the change causing the current test failures, some changes in OpenMDAO 3.40 mean that the integrator subsystem that the IntegratorGroup automatically adds is being ignored. See OpenMDAO/OpenMDAO#3621 for details. Not sure if this is something they will fix or whether we'll have to figure out another way to do this.

[davidszt2]

Hey @davidszt2, thanks for getting the ball rolling on this. Turns out the information that was in _var_abs2prom is now stored in _resolver._abs2prom. Annoyingly the promoted names in _resolver._abs2prom are stored in a tuple along with some other data so you can't access them in exactly the same way you would with _var_abs2prom. I wrote a little helper function to get the promoted name from whichever abs2prom dictionary is available and converted the code to use that.

Aha - I must've missed that attribute back then! Cool to see this is being worked on. Thanks for the awesome work you guys do as always!

[A-CGray]

@kanekosh , let's leave the IntegratorGroup issue for a different PR since that's an issue with OM 3.40 not 3.39.

I can't figure out why, but the remaining failing tests are being caused by this commit, it may actually be more of an issue with our unit test than with OpenMDAO itself

[kanekosh]

@kanekosh , let's leave the IntegratorGroup issue for a different PR since that's an issue with OM 3.40 not 3.39.

I can't figure out why, but the remaining failing tests are being caused by this commit, it may actually be more of an issue with our unit test than with OpenMDAO itself

Tests were failing because OM dropped supporting hybrid promoted variable names in 3.39 (OpenMDAO/OpenMDAO#3512) but some of our tests were using these. I fixed variable names so this should fix the tests