Remove dynamic allocations from swarm particle creation

[brryan]

PR Summary

Swarms previously created multiple ParArrays during the AddEmptyParticles call to create new particles. This PR pre-allocates that memory during resize operations and returns an accessor to new particle indices, resolving that issue.

This necessarily breaks previous usage of the AddEmptyParticles function and will affect all downstream codes using particles.

API change:

ParArray1D<bool> Swarm::AddEmptyParticles(const int num_to_add, ParArrayND<int> &new_indices)

is now

NewParticlesContext Swarm::AddEmptyParticles(const int num_to_add)

where NewParticlesContext adds the methods int GetNewParticlesMaxIndex() that returns the max index of the new particles -> swarm index map, and int GetNewParticleIndex(const int n) converts a new particle index to the swarm index.

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

[Yurlungur]

Overall this seems like a pretty minor change, but good for performance. And I like the new API, which feels cleaner. 👍

[brryan]

Alright this is ready for review/merge

[Yurlungur]

@pgrete or @bprather maybe one of you can review?

[bprather]

LGTM. I'm not far enough into particles to be annoyed by the slight interface change, and this is clean and easy enough to understand with the example.

[pgrete]

LGTM and the changes make sense from a performance point of view.
The main snarkyke case-y comment I have why you chose you use camel case (and even refactor some existing variables) versus snake case.
I'm general in favor of consistent style across the code base.

[brryan]

LGTM and the changes make sense from a performance point of view. The main snarkyke case-y comment I have why you chose you use camel case (and even refactor some existing variables) versus snake case. I'm general in favor of consistent style across the code base.

@pgrete You are absolutely right about the case style issue with variable names, I was mistakenly taking this in the wrong direction. Thanks for pointing that out. If I didnt miss anything, I've switched every variable in swarm over to camel case. This should be ready for merge now if you're happy

[brryan]

Alright all concerns look to be addressed to me so setting this to automerge, thanks all for reviews.