Closed hhollenb closed 2 months ago
Oh nooooo I thought we talked about this at the hackathon, but the "inserter" stuff is legacy crap that we used to populate data before we had Collections. I'll take a look at this later but we want to change the physics code (which is basically the oldest in our code base) to be more like the more contemporary code... this is the danger of not updating (or at least warning about!) obsolete code 😞
Initially, the
GenericGridBuilder
was designed to accept a scalarCollection
that it would immediately populate with generic grid data, and return aGenericGridData
. This is the opposite of theValueGridBuilder
which we use inStepLimitBuilders
, which caches the grids to be built and then populates aCollection
when aValueGridInserter
is supplied. I later added theGenericGridInserter
on top of this to combine the steps of building aGenericGridData
grid and putting it into a gridCollection
, returning its new ID in the collection.To have optical physics more closely mimic the conventions of core physics, I've refactored some of the
GenericGrid
classes. All classes calledBuilder
are now intermediate objects which will later supply their grids to classes calledInserter
, which are responsible for the actual population of grids in a givenCollection
.GenericGridBuilder
--> nowGenericGridSingleInserter
. The termSingle
is meant to signify that only the real scalarCollection
is populated, and the directGenericGridData
object itself is returned.GenericGridInserter
has mainly the same behavior. Instead of usingGenericGridBuilder
previously it's now updated to use theGenericGridSingleInserter
.GenericGridBuilder
. As withValueGridBuilder
it caches the raw data for a generic grid and can be called later to populate aCollection
in the usualStepLimitBuilder
algorithm. Itsbuild
method is templated based on the inserter, so that aGenericGridInserter
that uses different ID types will return the correct ID.Appropriate changes in existing code have been made to use the right classes.