This MR introduces the notion of a SwarmPack. It is a stripped down version of SparsePack, tuned towards particle swarms, to enable packing over MeshBlocks. I have preliminarily settled on a design wherein one can pack a SwarmPack via a std::vector<std::string> or the type-based variable prescription previously used in SparsePacks. SwarmPacks are unique from SparsePacks in that we must be able to handle both Real and integer types. In this MR, I do not allow SwarmPacks to contain mixed types, however, one can create a pack of Real swarm variables and a separate pack for int swarm variables. The design follows:
by std::vector<std::string> (where the template argument specifies that the data type):
std::vector<std::string> vars{swarm_position::x::name(),
swarm_position::y::name(),
swarm_position::z::name()};
static auto desc = MakeSwarmPackDescriptor<Real>(swarm_name, vars);
auto pack = desc.GetPack(md);
by type-based vars (where the data type is inferred from var-types):
static auto desc = MakeSwarmPackDescriptor<swarm_position::x,
swarm_position::y,
swarm_position::z>(swarm_name);
auto pack = desc.GetPack(md);
There are so many opportunities to further clean up things here... One could imagine (1) allowing mixed types in packs, (2) allowing for packing via Metadata or regex, or (4) combining SparsePacks and SwarmPacks, to name a few.
This MR adds the SwarmPack machinery to the particle_leapfrog test.
Finally, I'd note that this MR also transitions swarm_data to belong to meshblock_data rather than pmb. This likely has consequence when considering copies of mesh_data registers (e.g., in RK staging). Any undesired manifestations from this change should be uncovered as we continue to test downstream. For one, the current design requires that downstream users interface with particles via the basemesh_data register.
PR Checklist
[x] Code passes cpplint
[x] New features are documented.
[x] Adds a test for any bugs fixed. Adds tests for new features.
[x] Code is formatted
[x] Changes are summarized in CHANGELOG.md
[x] Change is breaking (API, behavior, ...)
[x] Change is additionally added to CHANGELOG.md in the breaking section
[x] PR is marked as breaking
[x] Short summary API changes at the top of the PR (plus optionally with an automated update/fix script)
[x] CI has been triggered on Darwin for performance regression tests.
[x] Docs build
[x] (@lanl.gov employees) Update copyright on changed files
[x] Include caching for SwarmPacks (cache cleared whenever Swarm::setPoolMax is called)
This MR introduces the notion of a
SwarmPack
. It is a stripped down version ofSparsePack
, tuned towards particle swarms, to enable packing overMeshBlock
s. I have preliminarily settled on a design wherein one can pack aSwarmPack
via astd::vector<std::string>
or the type-based variable prescription previously used inSparsePack
s.SwarmPack
s are unique fromSparsePack
s in that we must be able to handle bothReal
andinteger
types. In this MR, I do not allowSwarmPack
s to contain mixed types, however, one can create a pack ofReal
swarm variables and a separate pack forint
swarm variables. The design follows:by
std::vector<std::string>
(where the template argument specifies that the data type):by type-based vars (where the data type is inferred from var-types):
There are so many opportunities to further clean up things here... One could imagine (1) allowing mixed types in packs, (2) allowing for packing via Metadata or regex, or (4) combining
SparsePack
s andSwarmPack
s, to name a few.This MR adds the
SwarmPack
machinery to theparticle_leapfrog
test.Finally, I'd note that this MR also transitions
swarm_data
to belong tomeshblock_data
rather thanpmb
. This likely has consequence when considering copies ofmesh_data
registers (e.g., in RK staging). Any undesired manifestations from this change should be uncovered as we continue to test downstream. For one, the current design requires that downstream users interface with particles via thebase
mesh_data
register.PR Checklist
SwarmPack
s (cache cleared wheneverSwarm::setPoolMax
is called)