Updated the pyUno options (unopy v0.4.15)

[cvanaret]

Purpose

This PR updates the pyUno options. The tolerances associated with loose tolerances were changed/renamed in unopy v0.4.15/Uno v2.9.1.

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

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

[marcomangano]

Tests fail because the docker images still use unopy==0.4.8. Let's try again after the docker images are updated.

I am now wondering if we should just move pip install unopy here and let meson deal with it...

[robfalck]

Thanks for the update @cvanaret

Not sure if github's automatic issue closure works from comments or not:
Resolves #500

[ewu63]

1. I agree we should delegate non-compiled optimizers to pyoptsparse to handle during its testing phase. No other packages in MDOLab depend on it. How should we go about doing that? @marcomangano @A-CGray I suppose it would be 1) remove unopy from docker, and 2) add it here. In the interim things will fail but that's perhaps expected.
2. I am in favour of keeping only a minimal set of defaults (that are likely more stable), and rely the rest on unopy to handle under the hood. What do you think @cvanaret ?

[A-CGray]

1. I agree we should delegate non-compiled optimizers to pyoptsparse to handle during its testing phase. No other packages in MDOLab depend on it. How should we go about doing that? @marcomangano @A-CGray I suppose it would be 1) remove unopy from docker, and 2) add it here. In the interim things will fail but that's perhaps expected.

I will probably keep it in our docker images anyway because it's nice to have. But I agree it'd be nice for pyoptsparse to handle. Right now we have a chicken and egg situation where we've merged a PR updating the unopy version in the docker images, but those new images won't be published until our docker CI passes, which won't happen until this PR is merged. Handling the unopy installation in the pyoptsparse CI would fix this.

2. I am in favour of keeping only a minimal set of defaults (that are likely more stable), and rely the rest on unopy to handle under the hood. What do you think @cvanaret ?

Not super familiar with the precedent in other pyOptSparse wrappers, but I think we should only be storing default options in pyOptSparse if we are deliberately overriding that default, or we alter the behaviour of the option (e.g the logger_stream option)

[marcomangano]

Putting myself on the spot because I triggered this whole roadblock when I first added UNO to docker without realizing that unopy contained the compiled libraries and not just the Python wrapper. My vote is for removing unopy from docker (this would also solve the CI/publication issue) and add it as a testing (?) dependency here (which would also resolve the test failures here).

If we do this, then it is also much easier to maintain the current set of default options - whatever they may be.

[cvanaret]

2. I am in favour of keeping only a minimal set of defaults (that are likely more stable), and rely the rest on unopy to handle under the hood. What do you think @cvanaret ?

The Uno options in pyOptSparse are already quite minimal 😅 But Uno is under active development and the option set changes pretty much daily. That said, the tolerances that changed from Uno v2.9.0 to v2.9.1 shouldn't change any more (sorry, I should have published a minor release because of the breaking changes).