Fix swarm memory management unit test failure

[brryan]

PR Summary

Right now multiple branches are failing in the CI with

38/51 Test #38: Swarm memory management ....................................................***Failed    0.01 sec
Filters: Swarm memory management
*** The MPI_Comm_dup() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[9b3082cbec2a:02162] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!

This should be fixed.

PR Checklist

• Code passes cpplint
• New features are documented.
• Adds a test for any bugs fixed. Adds tests for new features.
• Code is formatted
• Changes are summarized in CHANGELOG.md
• Change is breaking (API, behavior, ...)
  • Change is additionally added to CHANGELOG.md in the breaking section
  • PR is marked as breaking
  • Short summary API changes at the top of the PR (plus optionally with an automated update/fix script)
• CI has been triggered on Darwin for performance regression tests.
• Docs build
• (@lanl.gov employees) Update copyright on changed files

[pgrete]

The CI machine is currently heavily loaded (I already contacted the user in question), so I'm wondering if this is an actual bug or sth weird popping up with a machine under heavy load.

Nevermind. This happened also for the MacOS runner, which is not shared...

[BenWibking]

So, err... does adding printf cause the error to go away? I tried re-triggering the CI actions, and I still don't see a problem...

Update: I triggered the macOS CI again...let's see what happens.

[brryan]

So, err... does adding printf cause the error to go away? I tried re-triggering the CI actions, and I still don't see a problem...

Update: I triggered the macOS CI again...let's see what happens.

So it just passed the macOS CI... so maybe this is an intermittent failure? Because it happens to this test on multiple CI workflows, even if only occasionally, I'll assume this is not fixed and I'll keep looking at this. Maybe it's some issue with how we're initializing the hierarchy of objects needed to create swarms...