Hi,
So far HydroBase only defines the typical primitive hydro variables (and more), but it doesn't use them to set Tmunu. This is currently done in GRHydro. Now, setting Tmunu only requires the primitive variables, so it could go into HydroBase (with a parameter to turn it off).
One application of this would be that it would be possible to have parameter files only calculating initial data, but also (correctly) calculating their constraints, without an active evolution thorn.
On the 'downside' this would introduce a dependency of HydroBase on TmunuBase, even with a parameter to turn it off. I don't think anyone would not use HydroBase without TmunuBase in the foreseeable future though.
What are the opinions about the proposal to move setting Tmunu from GRHydro to HydroBase?
Frank
On Tue, Aug 3, 2010 at 11:38 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
So far HydroBase only defines the typical primitive hydro variables (and more), but it doesn't use them to set Tmunu. This is currently done in GRHydro. Now, setting Tmunu only requires the primitive variables, so it could go into HydroBase (with a parameter to turn it off).
One application of this would be that it would be possible to have parameter files only calculating initial data, but also (correctly) calculating their constraints, without an active evolution thorn.
On the 'downside' this would introduce a dependency of HydroBase on TmunuBase, even with a parameter to turn it off. I don't think anyone would not use HydroBase without TmunuBase in the foreseeable future though.
What are the opinions about the proposal to move setting Tmunu from GRHydro to HydroBase?
I think this is a splendid idea. HydroBase must anyway have sufficient information to determine the complete state vector (otherwise one couldn't initialise GRHydro from it), and thus moving the Tmunu calculation to HydroBase will simplify our codes.
-erik
Hello all,
On the 'downside' this would introduce a dependency of HydroBase on TmunuBase, even with a parameter to turn it off. I don't think anyone would not use HydroBase without TmunuBase in the foreseeable future though.
Wouldn't doing simulations using the Cowling approximation not require TmunuBase?
What are the opinions about the proposal to move setting Tmunu from GRHydro to HydroBase?
I have slight preference for not having HydroBase setting Tmunu since doing so adds code to HydroBase making it a more active thorn and not just a thorn that defines a common interface for other thorns.
Yours, Roland
Hi,
On Wed, Aug 04, 2010 at 08:32:56AM -0400, Roland Haas wrote:
Hello all,
On the 'downside' this would introduce a dependency of HydroBase on TmunuBase, even with a parameter to turn it off. I don't think anyone would not use HydroBase without TmunuBase in the foreseeable future though.
Wouldn't doing simulations using the Cowling approximation not require TmunuBase?
What are the opinions about the proposal to move setting Tmunu from GRHydro to HydroBase?
I have slight preference for not having HydroBase setting Tmunu since doing so adds code to HydroBase making it a more active thorn and not just a thorn that defines a common interface for other thorns.
one thing to keep in mind is that there are multiple definitions of the 3-velocity out there. HydroBase would have to 'know' which on a given hydro thorn is using to be able to set up Tmunu.
- Christian
On Wed, Aug 4, 2010 at 8:51 AM, Christian D. Ott cott@tapir.caltech.edu wrote:
Hi,
On Wed, Aug 04, 2010 at 08:32:56AM -0400, Roland Haas wrote:
Hello all,
On the 'downside' this would introduce a dependency of HydroBase on TmunuBase, even with a parameter to turn it off. I don't think anyone would not use HydroBase without TmunuBase in the foreseeable future though.
Wouldn't doing simulations using the Cowling approximation not require TmunuBase?
What are the opinions about the proposal to move setting Tmunu from GRHydro to HydroBase?
I have slight preference for not having HydroBase setting Tmunu since doing so adds code to HydroBase making it a more active thorn and not just a thorn that defines a common interface for other thorns.
one thing to keep in mind is that there are multiple definitions of the 3-velocity out there. HydroBase would have to 'know' which on a given hydro thorn is using to be able to set up Tmunu.
To avoid confusion, the velocity in HydroBase must always have the same definition, independent of the evolution code. This is currently the same convention as Whisky/GRHydro.
If we keep the Tmunu calculation out of HydroBase, then we should still have it in one central place, and not repeat it in every hydro evolution code. We could introduce a new thorn CalcTmunu that inherits from both HydroBase (reading its variables) and TmunuBase (setting Tmunu). Personally, I find this more complex than necessary, and there is the danger that people will forget to activate this thorn, so I would instead include this functionality directly in HydroBase. For Cowling, the TmunuBase variables won't have storage, and HydroBase can detect this.
-erik
users@lists.einsteintoolkit.org
-
Christian D. Ott -
Erik Schnetter -
Frank Loeffler -
Roland Haas