[Paraview-developers] Some documentation on MTime handling?

[Utkarsh Ayachit]

You may also try `valgrind`, if you haven't already. It's great at
catching such memory issues.

Utkarsh

On Tue, Mar 20, 2018 at 6:50 PM, Cornelis Bockemühl
<cornelis.bockemuehl at gmail.com> wrote:
> Thanks - that gives me already a trace to follow: "mtime != pipeline time"!
>
> And thanks also for the offer to have a look into the code! However I guess
> that if I really have some pointer problem, like writing unallocated memory
> or the like, this is not in one single file but some "fatal cooperation"
> between program parts...
>
> I will have to step by step comment out functionality, see where it goes
> away and so narrow the potentially "guilty code"...
>
> Regards, Cornelis
>
> Gesendet mit BlueMail
> Am 20. März 2018, um 21:43, Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
> schrieb:
>>
>> Cornelis,
>>
>> I don't see anything fundamentally wrong about your approach (except that
>> you're assuming the input to this will never change dramatically enough to
>> invalidate all the caches, but let's assume that's the case).
>>
>> If you're getting segfaults due to `GetMTime`, it's actually something
>> else that's doing on, some bad ptr, access, etc. MTime is different from the
>> pipeline time. MTime is just a timestamp on VTK objects to indicate when
>> they were last modified, for example. If you share your filter.cxx, I can
>> see if I can spot the issue.
>>
>> Utkarsh
>>
>> On Tue, Mar 20, 2018 at 1:19 PM, Cornelis Bockemühl
>> <cornelis.bockemuehl at gmail.com> wrote:
>>>
>>> My short question is: I am having some problems to understand time
>>> handling in VTK, so I would like to find some documentations that can
>>> enlighten me! So far my Google research has only shown me that a) there have
>>> been different approaches in the past (which I do not need to understand)
>>> and b) there are many more options available than I will ever need to use...
>>>
>>> The specific problem that I am dealing with is in a project. In a filter
>>> that is supposed to run inside ParaView I am programmatically generating a
>>> time series of unsigned grids and tables, i.e. the filter has several
>>> several output ports that all have to change per time step. Empirically I
>>> found out that I have to put this code into RequestInformation:
>>>
>>>     // tell the caller that we can provide time varying data and specify
>>> the range
>>>
>>>     double tRange[] = {0., 1.};
>>>
>>>
>>>     // generate a vector with the steps - from 0 to NumSteps
>>>
>>>     Steps.resize(NumPeriods + 1);
>>>
>>>     for(int s = 0; s <= NumPeriods; ++s)
>>>
>>>         Steps[s] = (double)s / (double)NumPeriods;
>>>
>>>
>>>     for(int n = 0; n < GetNumberOfOutputPorts(); ++n)
>>>
>>>     {
>>>
>>>         vtkInformation* info = outputVector->GetInformationObject(n);
>>>
>>>         info->Set(vtkStreamingDemandDrivenPipeline::TIME_RANGE(), tRange,
>>> 2);
>>>
>>>         info->Set(vtkStreamingDemandDrivenPipeline::TIME_STEPS(),
>>> Steps.data(), Steps.size());
>>>
>>>         info->Set(CAN_HANDLE_PIECE_REQUEST(), 1);
>>>
>>>     }
>>>
>>>
>>> Some of the calculations are a bit tedious, so I am caching many data in
>>> the filter object, but not more than so far required. This means that in
>>> RequestData a decision has to be taken if more data need to be calculated
>>> first, or else directly copy from the cached data, like for example this:
>>>
>>> - jump to step 5 of 20 directly -> calculate steps 1 - 2 - 3 - 4 - 5
>>> internally, then copy data from step 5 to the output ports
>>>
>>> - jump back to step 3 -> simply copy the data from step 3 to the output
>>> ports
>>>
>>> - jump to step 7 -> calculate steps 6 - 7, then copy etc.
>>>
>>> During the calculations I am using other filters for some data
>>> processing, not attached to the pipeline, for some data transformations. For
>>> some time this worked now "somehow", but now I am suddenly getting crashes
>>> in one of these "detached filters" - when some "trivial producer" wants to
>>> ask for MTime - which is completely irrelevant in that context...
>>>
>>> In other words: I am now a bit confused - and at the same time I am
>>> afraid that I cannot easily strip down my problem to a size that I can
>>> easily share!
>>>
>>> Specifically I am not sure which way to try further:
>>>
>>> - somehow "tell the filters" that they should not care about time?
>>>
>>> - reconsider my caching because maybe it interferes with some similar
>>> functionality that is already built into ParaView?
>>>
>>> - somehow "tell" the output unstructured grids and tables which is their
>>> current MTime? But so far I thought I had understood that this is managed by
>>> ParaView, not by the data objects...
>>>
>>> ...but then some of the data objects have a GetMTime function, but no way
>>> to explicitly set this fabulous MTime: where does it come from?
>>>
>>> Actually such a call is the location where the program crashes!
>>>
>>> Regards,
>>> Cornelis Bockemühl
>>>
>>> ______________________________ _________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at:
>>> http://markmail.org/search/?q=Paraview-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://public.kitware.com/mailman/listinfo/paraview-developers
>>>
>>
>