[Users] TwoPunctures and [xyz]_offset

Erik Schnetter schnetter at cct.lsu.edu
Thu Jun 24 08:24:51 CDT 2010


On Jun 24, 2010, at 1:23 , Ian Hinder wrote:

> On 23 Jun 2010, at 14:25, Frank Loeffler wrote:
> 
>> On Wed, Jun 23, 2010 at 02:06:13PM -0400, Ian Hinder wrote:
>>> I'm confused about what parameters you are talking about.  In
>>> EinsteinInitialData/TwoPunctures/param.ccl, there is a parameter
>>> center_offset[i].  Is this the one you are referring to?
>> 
>> That is right.
>> 
>>> We do use this parameter for unequal mass BBH simulations.
>> 
>> I suspected so.
>> 
>>> If so, in what way is it broken?
>> 
>> It changes the grid functions x, y and z by that offset. You might be
>> lucky and Carpet might overwrite that before the first time step
>> though.
>> 
>> Do you still get the same results of you comment out the lines around
>> 621 in TwoPunctures.c (the whole loop basically)?
> 
> I computed initial data before and after this change and wrote the  
> BSSN conformal factor to HDF5.  I then used h5diff to compare the  
> resulting files.  There were no differences apart from the build-id  
> and simulation-id.  However, the coordinates themselves *do* show  
> differences, which I need to look into in more detail.  The only thing  
> I can think of in a BBH simulation which uses the coordinates  
> gridfunctions is wave extraction, as they are often used to compute  
> the tetrad.  Are they also used by the interpolator?

No, the coordinate grid functions are only used by initial data.  The PUGH and Carpet interpolators assume coordinates that can be expressed as "offset with delta", which is much more efficient than looking at grid functions.

Since one knows during wave extraction where the extraction sphere is located, the coordinate grid functions are probably also not used there (but this depends on the code).  I assume that one would not interpolate coordinates (since this should be an identity), therefore errors in the coordinate grid functions should not matter there either.

>  According to the  
> schedule.ccl of CartGrid3D, it looks like the coordinates are reset on  
> regridding.  So it might be that the initial portion of the waveform  
> before the first regridding is using incorrect coordinates.  Luckily  
> this portion of the waveform will almost certainly be before even the  
> junk radiation in a typical simulation, so I think the impact of this  
> should be minor.  I will run a short test BBH simulation before and  
> after this change and see what is affected.


-erik

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





More information about the Users mailing list