[Users] [Commits] [svn:einsteintoolkit] Paper_EinsteinToolkit_2010/examples/bbh/ (Rev. 85)

[Bruno C. Mundim]

Hi Roland:

Roland Haas wrote:
> Hello Bruno,
> 
>>  a) Its evolution is stopped with Nans around 8.6M. Nans appear to come
>>  from the BSSN fields, but still needs further investigation.
> Hmm I could evolve the qc0 example in McLachlan. Maybe there are
> differences in the parameter file that make the error "obvious".
> 
A few obvious changes that I can think of:

1) I reduced the number of spherical surfaces from 5 to 3. Now the 
puncture tracker uses surfaces 0 and 1, AHFinderDirect track those
surfaces and load AH related info there. QLM, CarpetTracker and
CarpetMask uses those 2 surfaces then. I will go back to 5 surfaces
as it was set before. Maybe I am missing some subtle scheduling order
here. I don't know.

2) I added a few general parameters I am used to use to CarpetInterp,
CarpetLib and CarpetRegrid2.

3) From a discussion I had with Peter on the ET workshop, I decided
to change the AHFinderDirect interpolator to Hermite.

So I will switch back to what it was and avoid to do so many changes
at once! :) However I find strange that these changes could be the
cause of what I am seeing.


>>  c) When CarpetReduce::weight is output, its values seem strange to me.
>>  Most of the domain has 1/2 set. A few points close to the boundary 1/4
>>  and the boundaries 0 (physical and ghost). No mask out values inside 
>>  AH is shown, ie they still are set to 1/2. These values seem to make
>>  more sense to AMR restriction operations.
> Are you maybe looking at the z=0 plane? That plane has a weight of 1/2
> since only half of the volume of each cell is used when eg. computing
> the simulation volume. I have never used CarpetMask myself (but have
> written a similar thorn of my own... would have paid to look into Carpet
> first I guess :-) )
> 
Yes I was looking at the z=0 plane and had refection symmetry set up!
Thanks for pointing this out. If we go out of the plane then the
weight=1.0 values show up. A more careful look into the data, I noticed
the zeros are set in the buffer zones indeed with the exception of the
third point (ghostzone=3) in the domain (from the AMR boundary) that has
its value set to 1/4. Do you know why?

Thanks,
Bruno.


> Yours
> Roland
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users