Support for Numpy 2.1 and OpenMDAO 3.35

[sabakhshi]

Purpose

Adds compatibility for Numpy 2.1 and OpenMDAO 3.35. Breaks backward compatibility with older OpenMDAO versions due to fundamental changes in how B-splines work in OpenMDAO 3.35.

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

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

[eytanadler]

Thanks for the PR. x_cp_start and x_cp_end need to be added to all spline components that take in the x_interp normalized interpolation locations (I think that’s all of them?), not just the t/c splines.

The testing problem is due to the fact that in the Docker containers being run on Azure, there is a Python package requirements file the constrains the versions of certain packages. This prevents pip from installing the OpenMDAO version we need. I think there are two ways to fix it. Either edit the OpenMDAO version in the Docker repo to edit the containers (this would affect the containers that all repos use) or create a new Python environment within the Docker container where the constraints file is no longer active (this would only affect OpenAeroStruct). Then run the tests with the new environment. Because this spline change requires the latest OpenMDAO and this is specific to OpenAeroStruct, I’m inclined to go with the second option. The first option would require changing to the latest OpenMDAO version in both the stable and latest Docker containers, which is probably undesirable (unless there’s a way to test OpenAeroStruct on only the latest containers, in which case maybe that would work). Let’s see what @kanekosh thinks.

[kanekosh]

I edited the GHA file to remove version constraints on numpy and openmdao (without editing the Docker repo itself), so the build process now installs OM 3.35+. However, it looks like the latest tests still run with numpy 1.25.2 ... should we explicitly test with numpy 2.1? (This would probably require a new Python environment within the Docker container like Eytan said)

[sabakhshi]

I fixed the splines for the structural components which greatly reduced the errors for the failed tests. I spoke to Ali about the discrepancies and we determined that they were consistent with the changes in the OpenMDAO spline component. Also most of the aerostruct tests use very coarse meshes making them very sensitive to the thickness related b splines. This is ready for review and merge.

[eytanadler]

A couple minor docs changes.

I'm not sure how the git merge was done, but I don't think the changes to the main branch from the MPhys 2.0 updates PR should show up in this diff. @kanekosh do you know what happened here? Or maybe this is fine.

[eytanadler]

OpenMDAO lower bound needs to be updated here.

[sabakhshi]

Done.

[eytanadler]

MPhys should be added here just as it is in the README.

[sabakhshi]

A couple minor docs changes.

I'm not sure how the git merge was done, but I don't think the changes to the main branch from the MPhys 2.0 updates PR should show up in this diff. @kanekosh do you know what happened here? Or maybe this is fine.

This branch was not up to date with the latest MPhys fixes from Tim Brooks. As result, the Mphys tests wouldn't run and I couldn't verify them with the changes in this PR. I did a git rebase with the main branch in order to add them to this branch. I might not have done that right.

[kanekosh]

A couple minor docs changes.

I'm not sure how the git merge was done, but I don't think the changes to the main branch from the MPhys 2.0 updates PR should show up in this diff. @kanekosh do you know what happened here? Or maybe this is fine.

Right, the diff is messed up... I don't know why (maybe because you merged from mphys branch not from the main?) and I'm not sure if the diff will be resolved when merging this PR into main.
I verified all the changes in the main were properly merged into this branch, so that's good.

We can try merging this into main, and hopefully the squash will sort out the diff issue (or not)?

Other than that, this PR looks good to me. Thanks @sabakhshi !

[eytanadler]

Sure, may as well try the merge.

Thanks again Big Saf!

The merge-base changed after approval.

[sabakhshi]

I have some concerns about merging into main with this. Should I not have used rebase from main to get the fixes from the last PR?

[eytanadler]

I would've thought rebase would be fine. But, GitHub also seems to have concerns because it instantly rejected my approval of the PR.

The merge-base changed after approval.

The merge-base changed after approval.