count evolved variables automatically in Refluxing

[Roland Haas]

the attached patch reliefs the user from some variable counting (there is still some) when using Refluxing and will automatically find out which variables are evolved with MoL and which use a non-MoL time integration scheme.

Keyword: Refluxing

[Roland Haas]

Anyone?

[Steven R. Brandt]

The patch I just attached does something similar, and hopefully more general. It changes the behavior of MoL so that it ignores the variable MoL_Num_Evolved_Vars, allocating the right amount of space as needed.

The change as attached passes the ET test suite, but it's incomplete (it doesn't address MoL_Num_Evolved_Vars_Slow, for example).

This is an effort to see what people think of this change in general.

[Roland Haas]

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.

[Erik Schnetter]

Please apply.

[Roland Haas]

applied as rev 75 of Refluxing.