On 30 Apr 2014, at 21:16, rhaas@tapir.caltech.edu wrote:
User: rhaas Date: 2014/04/30 02:16 PM
Modified: /trunk/src/ tov.c
Log: respect ADMBase::initial_shift parameter
Before this commit TOVSolver extended ADMBase::initial_shift to allow a "tov" keyword value. However it did not actually check anywhere that this value was set and instead set the shift to zero unconditionally if TOV_Clear_Initial_Data and not TOV_Use_Old_Initial_Data (line 546 of tov.c).
It should instead have checked the value of this parameter and set the shift to zero if the parameter says "tov" independent of TOV_Clear_Initial_Data etc.
This sounds like something that could change the behaviour of existing parameter files; maybe it shouldn't be applied until after the release?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Ian,
This sounds like something that could change the behaviour of existing parameter files; maybe it shouldn't be applied until after the release?
One would think so, yes. However due to other things that TOVSolver does, this change does not affect any current parfile (that produces correct result, ie does not read uninitialized data).
TOVSolver contains a parameter TOV_Clear_Initial_Data which defaults to yes and which sets all of gxx,gxy,gxz,gyy,gyz,gzz,k*, betax,betay,betaz,alp, rho,eps,vel to zero (not Minkowski). This is where currently shift=0 for TOVsolver is generated. This will still happen after the commit. The only difference is in betax_p etc. which were not initialized before (and had to rely on carpet's fill_three_timelevels or mol's initial_data_is_crap).
With this patch betax is set to zero twice.
So: this is a bugfix towards the failure of tov_slowsector that you observed. The bugs there go deeper (since the hydro initial data is so convoluted) and this is only partial fix.
Yours, Roland
- -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
users@lists.einsteintoolkit.org
-
Ian Hinder -
Roland Haas