[Carpet] IOBasic output issues

[Wolfgang Kastaun]

Erik Schnetter wrote:
> On Sep 19, 2006, at 13:07:47, Wolfgang Kastaun wrote:
> 
>> Erik Schnetter wrote:
>>
>>> I think the "triggers" mechanism is too simplistic for mesh   refinement
>>> with subcycling in time.  It may need to be extended.
>>>
>>>> -If I perform 1D/2D runs with no ghostzones in  one or two  directions,
>>>>  and demand reductions of variables which are only computed when
>>>>  triggered by an IO routine, I get:
>>>>  build/CarpetReduce/reduce.cc:1103: int CarpetReduce::ReduceGVs  (const
>>>> cGH*, int, int, int, void*, int,
>>>>  const int*, const CarpetReduce::reduction*):
>>>>  Assertion `nghostzones[d]>=0 && 2*nghostzones[d]<=lsh[d]' failed.
>>>>  Maybe this is connected to the problem above.
>>>
>>>
>>>
>>> This seems unrelated to me.  If you have zero ghost zones, then the
>>> assertion should succeed.  What are the values of nghostzones and of
>>> lsh at these lines?
>>>
>> lsh=1, nghostzones=2
>> I was talking of outer ghost zones (boundary points). Carpet
>> seems to check if internal ghostzones fit into the domain ?
> 
> 
> Ah, the confusion due to terminology.  In Cactus, "ghost zones" are 
> always points used for inter-processor communication.  Near the outer 
> boundary, there are either "boundary zones" or "symmetry zones".
> 
>> I attach the par file.
> 
> 
> Thanks.
> 
> At first glance, this assertion seems to be over-zealous; it should  not
> be tested near outer boundaries.  As a short-term work-around,  you
> could try commenting out this line.  I haven't looked whether  later
> code makes the same assumption, so you may get into trouble for  that.
> 
> You can also set different numbers of ghost zones (Cactus ghost  zones,
> not boundary zones) in different directions.  This may be the  more
> appropriate thing to do.
> 

O.k, the workaround
driver::ghost_size_z = 0
did the trick.