[Carpet] commit 1dd96e20cb7a87d294c5298b46f01dff97b0da53 broke testsuites

[Erik Schnetter]

On Apr 22, 2008, at 00:50:00, Baiotti Luca wrote:

> Hallo Erik,
>
> your commit
>
>
>
> 1dd96e20cb7a87d294c5298b46f01dff97b0da53 is first bad commit
> commit 1dd96e20cb7a87d294c5298b46f01dff97b0da53
> Author: Erik Schnetter <schnetter at cct.lsu.edu>
> Date:   Wed Mar 19 11:13:13 2008 -0500
>
>     Carpet: Schedule postinitial bin  before recursive initialisation
>
>     Schedule the postinitial bin before the recursive initialisation.
>     This is necessary because e.g. the conversion from ADM to BSSN
> variables
>     is performed in this bin, and this needs to occur before the  
> recursive
>     initialisation so that the refinement boundaries of the BSSN  
> variables
>     are initialised correctly.
>
> :040000 040000 2880633cc0512a536e16f303ba5ae62fadbb2478
> 7d7f3db0b50126c7756f21842c4be51555abe105 M	Carpet
>
>
>
> broke the Whisky testsuites. Differences appear in particular at  
> points
> of the coarsest level (which are not restricted, by the way).
>
> Did you expect that? Is the new, current version of carpet the  
> correct one?


No, I did not expect that.  Yes, the current version of Carpet is  
correct.

This patch corrects an error in the interaction between MoL and  
Carpet's recursive initialisation.  For example, the ADM variables are  
converted to the BSSN variables, and the BSSN variables then need to  
have their boundary conditions applied before the recursive  
initialisation of the finer grids, so that finer grids can have their  
mesh refinement boundaries interpolated from coarser grids.

This patch corrects an inconsistency.  In some cases some variables  
were not initialised or were initialised differently than they should  
have been.  I found this while setting up a new benchmark that uses  
Whisky.  I'm sure I set up my parameter file different than others (it  
wasn't using BSSN_MoL), but the inconsistency was real: MoL_PostStep  
was scheduled after the recursive initialisation, which is wrong.  I  
expect that most codes contain ad-hoc work-arounds for this  
inconsistency, e.g. by scheduling or applying boundary conditions  
explicitly in the INITIAL bin.

I checked Whisky, and I thought it was fine except for  
Whisky_TOVSolverC which I updated.

Which test case is breaking?  I see for example  
whisky_test_Carpet-3levels_RotNS failing for the velocities and the  
Hamiltonian constraint.  The velocities are identical at t=0, only  
small differences develop at later times -- I do not know whether they  
are significant.

I think that Whisky is not included in the automated build tests on  
portal.aei.mpg.de.  Should we include it?

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : /archives/developers/attachments/20080422/04ea8342/attachment.pgp