[Paraview-developers] Starter for generating time series of objects

[Utkarsh Ayachit]

Cornelis,

CONTINUE_EXEUCTING is not really intended for streaming, as you are
expecting to use it in (b).  What you could do is spawn a thread in
your code and "continue" producing timesteps for sub sequent requests,
potentially.

(2) you can add a information_only property that is used to get the
range for the domain for the property that's controlling the range.
e.g. https://gitlab.kitware.com/utkarsh.ayachit/paraview/commit/3d371600251061c1ea885ade65284bf978152f78#131237b3d972deefa8d0797ebaf39ad317daf3d9_28_98

But paraview doesn't like for forcibly set values set by the user,
hence while the slider range may update, the value the user set won't
change.

Utkarsh

On Fri, Sep 22, 2017 at 5:29 PM, Cornelis Bockemühl
<cornelis.bockemuehl at gmail.com> wrote:
> So far so good: I am now able to generate a series of variants of my
> unstructured grid - like what I wanted.
>
> Mostly - because there are still two things that I do not seem to get right
> - a smaller and a bigger problem:
>
> 1) the smaller: I can choose between two variants, but both are not 100%
> what I would like most:
>
> a) the user presses "Apply" - and only the first step of the animation is
> calculated and displayed. Only by using the "Play" button all the other
> steps are first calculated, then shown. Pressing "Play" again replays the
> same sequence that is now read from a cache.
>
> b) once the user presses "Apply", the entire animation is calculated -
> without any display! - and then the final step is shown. This I achieve by
> using the
> "request->Set(vtkStreamingDemandDrivenPipeline::CONTINUE_EXECUTING(), 1);"
> command accordingly. The user needs to press "Play" now in order to see the
> animation (now from the cache).
>
> Ideally I would like to see variant b), but with displaying all the
> intermediate steps immediately. However, I have the impression that the
> CONTINUE_EXECUTING flag is maybe not really for that purpose, but more for
> "writers" that need to produce one step after another. Since that
> intermediate display is not possible, then variant a) looks like the better
> one.
>
> Short: If there is no solution to this problem currently, I could live with
> variant a) (and hopefully also my users)
>
> 2) the more difficult problem is the fact that even if the user defines a
> number of steps initially (in the property panel), my algorithm is such that
> it is not guaranteed that the number of steps can be achieved at all! Like:
> the user asks for 10 steps, but only 7 can be found - no more solutions
> after that. And what is worse: this cannot be seen in advance, without doing
> the entire calculation! Which can take some time...
>
> What I could do so far is stopping after 7 steps, even changing the maximum
> number of steps for the moment to that value, but this is then not reflected
> in the properties panel: that shows still 10! And also the "player" runs are
> still assuming that 10 steps should be produced. Ok, this can be somehow
> handled in the RequestData function in the Algorithm class, but it would be
> nicer if that Algorithm class could "tell" the properties panel and the
> player that it is now about 7 steps, not 10 any more!
>
> In other words: Can I not only retrieve values from the properties panel in
> the Algorithm class, but also send some values back and have them adapted in
> the widgets there?
>
> I see that I still have a lot to learn about the workings of the different
> parts and their interaction in the VTK/Paraview world, but in a few weeks I
> will hopefully get much more insight during two days of training at Kitware
> in Lyon ;-)
>
> Regards,
> Cornelis
>
>
> 2017-09-20 7:43 GMT+02:00 Cornelis Bockemühl
> <cornelis.bockemuehl at gmail.com>:
>>
>> Thanks a lot Utkarsh!
>>
>> It looks like your hints are giving me the theoretical background.
>> Additionally I realized that the vtkTimeSourceExample.h/cpp provides a
>> simple skeleton for implementing a filter that produces a time series
>> programmatically in C++.
>>
>> Not finished yet, but I think I am on the right track now!
>>
>> Regards, Cornelis
>>
>>
>> 2017-09-19 15:58 GMT+02:00 Utkarsh Ayachit <utkarsh.ayachit at kitware.com>:
>>>
>>> Check out Section 13.2.2 in the ParaView Users Guide. It describes
>>> steps needed for a Python Programmable Source that produces time.
>>> That's pretty much the same thing you'd need to do in your temporal
>>> filter.
>>>
>>> A bit more background is available here:
>>> https://blog.kitware.com/streaming-in-vtk-time/
>>>
>>> Utkarsh
>>>
>>> On Mon, Sep 18, 2017 at 10:33 AM, Cornelis Bockemühl
>>> <cornelis.bockemuehl at gmail.com> wrote:
>>> > Dear Paraview/VTK programmers,
>>> >
>>> > Right now I need to write a filter for Paraview that takes an
>>> > "unstructured
>>> > grid" as input and generates a time series as an output. I.e. a series
>>> > of
>>> > unstructured grids, derived from the first, with many points and data
>>> > remaining the same and a few changing, including changing a few
>>> > attribute
>>> > values of cells and also changing the number of cells. No absolute time
>>> > is
>>> > required, so the steps can simply be numbered 0...1...2 etc.
>>> >
>>> > At this moment I am a bit lost about where to start for learning to do
>>> > such
>>> > a thing, so I would be happy with some starter: "look into ...
>>> > documentation/tutorial" or "look into this .... source code"!
>>> >
>>> > The only possibility I see at this moment is to generate the
>>> > unstructured
>>> > grids timestep by timestep, write them as a series of VTK files with an
>>> > index number in the file name, and then load it into Paraview.
>>> >
>>> > However, since Paraview can read such a sequence completely into memory
>>> > -
>>> > why should not my filter also do the same? But what is then what
>>> > Paraview
>>> > has in memory: a sequence of objects with timestamps somehow assigned?
>>> >
>>> > With this I would have the question of how I can assign a timestamp to
>>> > an
>>> > unstructured grid?
>>> >
>>> > Also the method of writing files first, then reading them seems a bit
>>> > inefficient in terms of memory management: In my specific case a big
>>> > number
>>> > of data would remain the same, so they could be shared like they are
>>> > also
>>> > shared along a pipeline of filters - with unchanged arrays just being
>>> > referenced and not copied.
>>> >
>>> > One more thing that I found out when trying to analyze the can example:
>>> > If I
>>> > read it from that can.ex2 file each one of the time steps has an
>>> > explicit
>>> > time value assigned - some very small number like 0.000<something>. If
>>> > I
>>> > write the object to a VTK file in full ASCII format in order to analyze
>>> > it I
>>> > do not find anywhere these time numbers. And if I read back the can
>>> > example
>>> > from the resulting can*.vtm series of files, the time stamps have
>>> > disappeared and I see only 1...2...3 etc. Not a problem in my case (as
>>> > already said above), but it leaves me again with the question of how to
>>> > assign "time" to my data programmatically: In the VTK files the only
>>> > indication seems to be the run index number of the file and subfolder
>>> > names!
>>> >
>>> > So again: I would be happy with some helpful hints about where I can
>>> > get
>>> > more information about the subject, either explained or from sourcecode
>>> > study!
>>> >
>>> > Thanks and regards,
>>> > Cornelis
>>> >
>>> > --
>>> > Cornelis Bockemühl
>>> > Basel, Schweiz
>>> >
>>> > _______________________________________________
>>> > 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:
>>> > http://public.kitware.com/mailman/listinfo/paraview-developers
>>> >
>>
>>
>>
>>
>> --
>> Cornelis Bockemühl
>> Basel, Schweiz
>
>
>
>
> --
> Cornelis Bockemühl
> Basel, Schweiz