[Users] [Commits] [svn:einsteintoolkit] TOVSolver/trunk/ (Rev. 137)

Roland Haas rhaas at tapir.caltech.edu
Mon Jul 8 05:11:34 CDT 2013


Hello all,

> I am undecided. I agree that it is pleasant to tidy things up and 
> make the current version clean.  But at the same time you have to 
> consider the disadvantages.   It is very frustrating when you are 
> trying to locate where a bug was introduced with historical versions
>  of the code if you can't use the same parameter file with old and 
> new versions.  If at all possible, I would try to make the old 
> parameter files still work.  If we had 100% test coverage (i.e. all 
> the code was exercised during the tests), then maybe we would have 
> the luxury of assuming that we never had to go back to old versions 
> to debug where someone broke something, but we are nowhere near
> that, so it is inevitable that we will have to do this from time to
> time, and if the code is not backwards compatible, this becomes
> somewhat of a crapshoot.  Often you can get the best of both by
> introducing a new parameter rather than changing the old one, though
> I haven't looked into the details of this particular issue so I don't
> know if that makes sense here.
Based on that it having different K (or Gamma) for different NS should
not be done since it is not physical (and no one objects to removing
this facility) then one way to keep most old parfiles (for single NS,
for binary NS we are changing results since the code changes) would be
to keep TOV_K a vector but reduce its size to 1. This will make the
parfile parser throw an error when the other parameters are set but
leave single star files alone (which are the majority of files out there
I hope since binaries are not constraint satisfying). This is somewhat
ugly since it means that there is a single parameter but it appears as a
vector. It would thus most likely be best to eventually change the
parameter to the way they are right now (after deprecating the current
one). A further alternative is to leave the ability for multiple K/Gamma
values, unify the atmosphere treatment in TOVSolver (ie let GRHydro do
it) and put a long comment as to the dangers of setting multiple K into
param.ccl. "Consider yourself warned ...".

I'll push patches for the remaining triviail failures (Trigger and
Outflow). There is one slightly non-trivial failure in TOVSolver itself
which requires a bit of digging into the code.

Yours,
Roland

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20130708/77e8397e/attachment-0001.bin 


More information about the Users mailing list