Phase out HistoryTrackerInterace

[john-science]

It appears @youngmit already did the bulk of the work to move the functionality people want from the HistoryTrackerInterface into Database3: 38d9feb

This seem preferable, as the data will be more accessible to anyone with a DB. Also, it reduces the complexity of having a whole Interface. On the surface, it seems like this is an easy change to make. The (apparent) steps to take now are:

1. Ensure that all the important functionality/data from the HistoryTrackerInterface is now in the DB.
2. Find all downstream projects that use the HistoryTrackerInterface, and switch them to using the DB.
   • There is an equilibrium history tracker subclass downstream.
   • And there is some code in crucible downstream that makes heavy use of it.

[ntouran]

Yeah so history tracker was originally made before we could read a case's own database during a run for historical info. It saved a subset of state data to ram that it could very quickly bring back as needed. Now that db3 can read itself during a run, it's largely not needed.

The internal equilibrium capability has lots of fanciness that maps an equilibrium cycle's shuffling into full multi-cycle time-dependent histories that must be maintained internally, but that can be done somewhere outside of the history interface.

[john-science]

The internal equilibrium capability has lots of fanciness...

Heck, I could copy/paste all the code they need into their project, if they need more than the "new" DB3 can provide.

[ntouran]

We do need to maintain a unified interface (e.g. that works in Equilibrium-mode or discrete case) to rapidly extract from the DB the value of any block or assembly-level param as a function of time including shuffling of one or more specific blocks/assemblies (again, equilibrium or not).

This is currently the main feature of the history tracker, and I think we do need to keep it.

This is essential, e.g. for fuel performance physics modules that need to see the entire flux/temperature/composition histories of each block in each assembly as they're computing e.g. expansion or fission gas removal.

Some of the parts of history tracker that e.g. make tabular reports of history data for some given assemblies/blocks could arguably be moved into a report interface that calls this essential functionality.

In summary, the getBlockHistoryVal method and the various optimizations in there that allow it to be performance need to remain in the framework, at least somewhere. This could potentially be moved into the DB interface, I guess, if we wanted.