[Paraview-developers] Some documentation on MTime handling?

Utkarsh Ayachit utkarsh.ayachit at kitware.com
Tue Mar 20 16:43:23 EDT 2018


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/38760d7c/attachment-0001.html>


More information about the Paraview-developers mailing list