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

[Ian Hinder]

On 8 Jul 2013, at 12:11, Roland Haas <rhaas at tapir.caltech.edu> wrote:

> 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.

Thanks.  We are now down to 4 failing tests:

	https://build.barrywardell.net/job/EinsteinToolkit/657/testReport/

Do you know why these are failing?

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20130711/36751cdf/attachment.bin