[Paraview-developers] Some documentation on MTime handling?

Tue Mar 20 18:50:19 EDT 2018

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 21:43, 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/paraview-developers/attachments/20180320/12786a7b/attachment-0001.html>