Support calling addObjective on subset of procs

[A-CGray]

Purpose

Adds a _finalizeObjectives method that reduces any added objectives across all procs so that all procs have the same objectives. This is already done for design variables and constraints.

Expected time until merged

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 added a small unit test that checks that all procs have the same objectives, constraints and design variables after finalize is called.

Checklist

• I have run ruff check and ruff format 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

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.72%. Comparing base (bee4701) to head (76e332f).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #465      +/-   ##
==========================================
+ Coverage   86.27%   86.72%   +0.44%     
==========================================
  Files          24       24              
  Lines        3432     3435       +3     
==========================================
+ Hits         2961     2979      +18     
+ Misses        471      456      -15     

☔ 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.

[ewu63]

So I don't believe this is a bug, we've never supported distributed objectives before since we've never needed to, only constraints/DVs. In any case, I think this was a pretty non-documented feature and this change LGTM.

[ewu63]

When does this condition happen?

[A-CGray]

If you have mpi4py installed but you run the test through something other than testflo (e.g unittest or pytest)

[ewu63]

IMO this sort of thing do not need to be handled, we explicitly say in the docs to run tests with testflo so I don't think we need to support running raw unittest.

[A-CGray]

True, but whenever I want to interactively debug a failing test I have to run them with unittest and I'd rather not have to comment this test out every time I want to do that. I guess I could also try changing how the test works so it won't fail if run in serial, but it seemed easier to just do this.

[ewu63]

I'll approve, but I don't think we should do things like this in general, because we have tons of MPI-based tests (here or in other repos) and we should not have to add these checks for each one. Maybe in the longer term we should move away from testflo-based testing to something more standard like pytest, it may not be sufficient for packages like ADflow but the parallel portions of pyOptSparse are minimal and easy to test.

[A-CGray]

So I don't believe this is a bug, we've never supported distributed objectives before since we've never needed to, only constraints/DVs. In any case, I think this was a pretty non-documented feature and this change LGTM.

Right, I don't think what I've implemented here actually supports objectives that are distributed at runtime (as in it still expects the same objective value to be returned on all procs when it calls masterfunc). Does pyOptSparse support constraints that are distributed at runtime? I didn't see anything in the code that suggests it does, but if it does then presumably I should add something similar to this PR?

[ewu63]

Does pyOptSparse support constraints that are distributed at runtime? I didn't see anything in the code that suggests it does, but if it does then presumably I should add something similar to this PR?

No it does not, that functionality lives in multipoint. I've long thought that multipoint could be moved into pyOptSparse or at least seen as a "plugin" for this repo, but that's probably a long-term discussion. My original point was just that we had never had the need to run an allreduce on the objective, since typically we just have one objective function which is available on all procs.

[ewu63]

I would be OK with a patch release after this PR is merged, feel free to bump the version. Alternatively we can wait for #459

[A-CGray]

I would be OK with a patch release after this PR is merged, feel free to bump the version. Alternatively we can wait for #459

Let's do it in #459