Refactor out the scratch hierarchy from IBFEMethod

[drwells]

This might be useful to have if we want to scale up IBMethod - it would also be nice for writing more classes like IBFEMethod (e.g., the deal.II equivalent). Cleaning up this interface will also make #1226 easier to understand since it will be clearer where the data goes with an explicit interface (instead of IBFEMethod owning everything.

[drwells]

@boyceg not urgent, but hopefully you know the answer - one of the next things to do is to calculate the workload, store it in the primary hierarchy, regrid the primary hierarchy, and then copy it over to the secondary hierarchy. Hence, a question: how do we add variables that are going to be regrided? I read through HierarchyIntegrator::registerVariable() but it isn't explicitly set anywhere.

[boyceg]

This version of HierarchyIntegrator::registerVariable() is intended to be used for persistent variables (i.e. that are automatically transferred during a regridding operation).

[drwells]

That works inside HierarchyIntegrator but I cannot figure out how to do it independently of our own code: do you know what exactly triggers the association?

Some things in particular that don't work:

• registering for restart
• calling grid_geom->lookupCoarsenOperator and grid_geom->lookupRefineOperator to do some kind of background registration
• either regridding just the coarsest level or all finer levels

i.e., we can do the regrid independently of everything else in IBTK (good) but it doesn't propagate data. See https://github.com/drwells/IBAMR/blob/088d5ec143fe93ce07b61c02e71cb8f514fbf9bf/tests/IBTK/scratch_hierarchy_01.cpp for my attempts.

[drwells]

In all cases, patch level data is no longer allocated after that level is regridded.

[boyceg]

You need to allocate and communicate the data you want to retain after regrid in an implementation of initializeLevelData(). See HierarchyIntegrator::initializeLevelData().

[boyceg]

This function is from StandardTagAndInitStrategy.

[boyceg]

Basically, when you regrid, you need to have a list of the patch data indices that you want to retain, along with suitable transfer operators for each to handle coarsening/refining.

[drwells]

I figured it out, but for the record - the answer is ultimately that one must keep the old patch levels around and then transfer whatever data you want to transfer from them using RefineAlgorithm et al.

[boyceg]

Oh yeah, if you throw away the level before you transfer the data, then you lose that data. This is handled more-or-less automatically in StandardTagAndInitStrategy.