[vtk-developers] Re: [ParaView3-Developer] Setting Update Extent

[Berk Geveci]

When I originally wrote that code, I assumed that each block in an AMR
grid would always be processed as a whole. Therefore, the code always
ask for the whole extent of each block. It looks like this assumption
is not valid when dealing with temporal datasets (and maybe with
multiblock datasets? I have to think about that). I am not sure "if
update extent not set ..." is the right check for multiblock/AMR
datasets since the update extent may be set from the previous block to
the wrong thing. I have to look at the code to see if the update
extent is cleared anywhere.

Day by day, I am growing more annoyed by the fact the executives much
with structured extents. I think that the executives should always
deal with piece extents and leave all the structured extent stuff to
algorithms. One day, I will become annoyed enough to rewrite the
composite data executive to do just that. If I only had 48 hours days
for a while :-)

-berk

On 2/19/08, John Biddiscombe <biddisco at cscs.ch> wrote:
> [snip intro]
>
>  I found two things, which I believe are to blame for incorrect
>  pieces/extents after temporal loop. Please anyone feel free to comment
>  on this. cc'd to vtk-dev ...
>
>  In TemproralDataSetCache, I put an extent check in and overwrote the
>  update extent. I remember doing this because pieces were not being
>  transmitted, but now they are (or should be), so I've removed it.
>
>  The second is much nastier...
>  in
>
>  vtkCompositeDataPipeline::ExecuteSimpleAlgorithmForBlock(
>
>  there is a piece of code here...
>
>       if (info->Has(
>                     vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT()))
>         {
>         int extent[6] = {0,-1,0,-1,0,-1};
>         info->Get(
>           vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(),
>           extent);
>         info->Set(
>           vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),
>           extent,
>           6);
>         info->Set(
>           vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT_INITIALIZED(),
>           1);
>         storedPiece =
>
>  info->Get(vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER());
>         storedNumPieces=
>
>  info->Get(vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES());
>         info->Set(
>           vtkStreamingDemandDrivenPipeline::UPDATE_NUMBER_OF_PIECES(),
>           1);
>         vtkDebugMacro(<< "UPDATE_PIECE_NUMBER() (a) 0"  << " " << info);
>         info->Set(
>           vtkStreamingDemandDrivenPipeline::UPDATE_PIECE_NUMBER(), 0);
>         }
>
>  which basically says if the whole extent exists, overwrite the update
>  extent (of the input information).
>  Now looking at the key/values as it comes in, the UPDATE_EXTENT is
>  actually correct - it was set earlier to the correct values - (question
>  is, was is set before the cache was instantiated, in which case it's
>  probably just luck that it's correct now), or was it set during the
>  earlier request information. Either way, the check I show above looks
>  like pants to me. It should at least be something like
>
>  if update extent not set .....
>
>  Imagine my surprise when the I changed it to that and it started
>  behaving correctly.
>
>  Can anyone tell me why the original check was as it was. In the
>  meantime, Berk is away it seems, so I'll sit on my fixes and run some
>  tests until stuff breaks....
>
>
>  JB
>
>
>
>  _______________________________________________
>  ParaQ-Developer mailing list
>  ParaQ-Developer at paraview.org
>  http://public.kitware.com/cgi-bin/mailman/listinfo/paraq-developer
>