[ET Trac] [Einstein Toolkit] #1435: count evolved variables automatically in Refluxing

[Einstein Toolkit]

#1435: count evolved variables automatically in Refluxing
------------------------------------+---------------------------------------
  Reporter:  rhaas                  |       Owner:                     
      Type:  enhancement            |      Status:  review             
  Priority:  minor                  |   Milestone:                     
 Component:  EinsteinToolkit thorn  |     Version:  development version
Resolution:                         |    Keywords:  Refluxing          
------------------------------------+---------------------------------------

Comment (by rhaas):

 I think the patches address different issues. The patch count_mol.patch is
 a patch to LSUThorns/Refluxing and deals with adding refluxing to
 variables that are not evolved using MoL. Right now the user of Refluxing
 has to count the number of variables that require refluxing that are
 evolved using MoL (ie all in GRHydro) and additionally has to count then
 number of variables that need refluxing but which are not evolved using
 MoL (which are currently the neutrino variables in the Zelmani code). The
 patch attempts to remove the need for counting the number of variables
 evolved using MoL (and therefore since the total number of evolved
 variables requiring refluxing is known  also the number of those variables
 not evolved by MoL) by querying MoL for each refluxed variable whether MoL
 is evolving this variable.

 Patch mol.patch attempts to do away with MoL_Num_Evolved_Variables
 accumulator. So it is a patch to MoL and addresses different counting
 problem. I agree that we want to avoid MoL_Num_Evolved_Variables and the
 proposed patch is a first step in this direction. Right now the patch
 seems incomplete in that it does not actually do anything about the
 MoL_Num_Evolved_Variables parameter which is used eg in interface.ccl to
 allocate storage for MoL::ScratchSpace.

 I propose to move the second patch into a ticket of its own. In fact I had
 worked on this in the patch an written a version of MoL that no longer
 requires any of the accumulators. I have copied this patch and my own
 patch(es) to ticket #1505. Please note that the method I chose while
 working is an abuse of the Cactus timelevels. A clean solution seems to
 require creation of new grid variables at run time.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1435#comment:4>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit