Automatic options prefix creation not safe in presence of objects on multiple communicators

[wence-]

The options manager produces, if the user does not provide one, a "unique" options prefix by incrementing a class-level counter.

If two ranks diverge and one of them makes more options managers than the other, this prefix will get out of sync.

This goes against the petsc model that PetscObjectSetOptionsPrefix is collective.

I think the reason it has never bitten is that in practice the options prefix only needs to agree locally with the names we shove in the options database.

To fix this, the OptionsManager could take the internal communicator, which would have a attribute attached that stores the count. Now you get collectively consistent counts, however, multiple communicators might have counts in the same state. I think this shouldn't matter because the optionsmanager only ever manages the options for a single object.

[JHopeCollins]

I also had the same realisation this week. It may occur for example if you are solving a time-parallel system where you have solvers on overlapping slices of the timeseries.

I don't think you need to stash anything on the comm if you do the following:

1. Use count.next() to get a candidate index on each rank.
2. Work out the maximum index over all ranks on the given comm, and use that to generate the prefix.
3. Any ranks that had a lower index than the one used for the prefix calls count.next() until it's up to date again.

You don't have to stash anything on the comm, the OptionsManager doesn't even need to keep a reference to the comm, and you'll never have two OptionsManager instances on the same rank with the same prefix.

[connorjward]

I don't think that that is necessarily a better solution as it requires a communication each time. Is it an issue if the prefix is duplicated between comms?

[JHopeCollins]

If an OptionsManager is using a default prefix then it doesn't grab anything from the global options database, so it won't cause any ambiguity for who each option belongs to, but it'll make monitor outputs confusing sometimes.

[connorjward]

If an OptionsManager is using a default prefix then it doesn't grab anything from the global options database, so it won't cause any ambiguity for who each option belongs to, but it'll make monitor outputs confusing sometimes.

I see. I am happy with either solution.