[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).

[A-CGray]

If I look here, there are only 3 options that we currently handle differently than Uno:

1. preset: because we the set the preset through set_preset() rather than setting an option. It seems that now you actually can set the preset through an option @cvanaret ? In which case we should remove this.
2. logger_stream: because we provide additional functionality, specifically the ability to pass a string rather than an already opened file stream
3. save_major_iteration_variables: because this controls functionality purely in the pyoptsparse wrapper, separate from unopy itself

IMO logger_stream and save_major_iteration_variables are therefore the only defaults that should be explicitly specified in _getDefaultOptions, everything else should be retrieved from unopy itself. That is assuming there is some method for retrieving the list of options and their defaults @cvanaret ?

[A-CGray]

@cvanaret the Uno options documentation show only auto, ipopt and filtersqp as the available preset values, but the code still seems to accept funnelsqp and filterslq (here). Is this intended?

[A-CGray]

I've updated the uno wrapper to set the preset through set_option rather than set_preset so it doesn't require any special handling. This relies on a bugfix in unopy 0.4.17.

@cvanaret unopy currently doesn't have any API for retrieving option values (either the currently set or default values). It seems like it does exist in the C++ API, if that could be exposed in unopy then we could get rid of most of the hardcoded options/defaults in _getDefaultOptions and automatically reflect the up to date options, even as they change between releases.