|
Notes |
|
|
(0010915)
|
|
Berk Geveci
|
|
2008-03-26 10:02
|
|
|
The problem here is that when the executive loops the exodus reader to produce multiple time steps, the output becomes a temporal dataset. This confuses paraview that expects a multi-block output. |
|
|
|
(0012623)
|
|
John Biddiscombe
|
|
2008-07-04 09:07
|
|
It's worse than just that.
The filter receives the TIME_DOWNSTREAM and the executive creates a temporal wrapper. If you have other filter between the source and the temporal filter, they also see the Temporal wrapper instead of the vanilla dataset (might not be multi-block etc) and they abort with messages like
Filtering\vtkDemandDrivenPipeline.cxx, line 825
vtkCompositeDataPipeline (0A846BA8): Input for connection index 0 on input port index 0 for algorithm vtkAMRDataGroupFilter(0A846188) is of type vtkTemporalDataSet, but a vtkImageData is required.
What should happen, is that the temporal dataset is created (which it is) at the output of the reader etc, but when the next filter gets its input, it should only get the Nth dataset from inside the temporal wrapper and not the wrapper itself.
This is causing me a lot of trouble, so I'm hoping berk will see this and look at it soon. if not, please let me know so that I can devote some time to it. |
|
|
|
(0013717)
|
|
John Biddiscombe
|
|
2008-10-03 06:04
|
|
There are a couple of things worth noting.
In the executive, there is a test to see "Is the data type correct:, which works like, if output is type A and filter wants type B, or if TEMPORAL_ requested, then change type. And one of the tests is if Data->IsTypeOf(blah), now when the output is composite, and the filter downstream is requesting Temporal. The test is wrong, becauze temporal is a type of composite. so the wrong data type flag is not set.
I did have a good look at this and I'm sure it's not going to be hard to get right, just a PITA to redo a lot of executive stuff. |
|
|
|
(0015049)
|
|
Ken Moreland
|
|
2009-02-17 14:07
|
|
|
I know that John is taking a second look at the temporal pipeline, so I'm going to assign this bug to him now. If this gets fixed amongst the other changes, great. If not, bounce this back to Berk. |
|
|
|
(0015979)
|
|
John Biddiscombe
|
|
2009-04-09 03:59
|
|
Adding contents of email from Dec 2008 for reference
----------------------------------------------------
I made a few changes to TemporalShiftScale and SnapToTimeStep last week which had unfortunate repercussions for the TemporalFractal test.
I've spent some time going over the executives and various classes which make use of TemporalData and I would like to make some changes to the whole temporal framework...
Problems : The main problem with the temporal design as it stands is that it is very difficult to know when a filter has got the right input or output when temporal looping is involved. The problem is largely caused by the TemporalDataSetAlgorithm Family. These classes export a TemporalDataSet directly, and it isn't possible to know what kind of datatype they have inside the collection.
Consider the case of the failing TemporalFractal Test.
A TemporalFractal class exports TemporalDataSet. Currently, this can only be connected to another class which takes TemporalData as input. Even if it only exports a single timestep, which may be uniform grid, or rectilinear, or even a hierarchy of either (Multiblock etc)
We would like the Executive to take temporal data and loop it for non temporal filters, but we can't connect a non temporal filter to it and get it right- because when the filters are connected together and first executed, the RequestDataObject pass for the filter accepting the TemporalDataSet doesn't know what type of output to create - we fudged around this by simply exporting a temporal dataset too (which is why snap and shift scale were TemporalAlgorithms (and they should not be, they do not change the type of data passing through them). There are several bugs existing (http://public.kitware.com/mantis/view.php?id=6662 [^]) which all stem from the problem that the executive needs to take a single dataset from a temporal collection and pass it into a non temporal filter - currently it just doesn't do it and we see the output of a filter change to temporal within the paraview gui and various other side effects once temporal stuff is initiated.
I'd am going to remove the whole TemporalDataSetAlgorithm family and instead have filters which declare themselves as (say) UniformGrid/Image/PolyData algorithms (or even multiblock), but export a new information key which says "I support temporal" if they are capable of delivering multiple time steps. Filters which require temporal collectios of type X, will add a key requesting time.
The advantages of this are
a) Filters will export a defined 'type', which other filters and the gui will be aware of, so temporal filters exporting polydata will be distinct from temporal filters exporting imagedata and so on. The user can then also write a filter which requires N Polydata and not any other type, currently the pipeline connects all temporal classes without checks.
b) The checks in the executive will be simpler. A filter needs temporal data, but the upstream pipeline exports simple, so loop. When a filter needs simple, but upstream has declared time support, we take the i'th dataset on iteration i (or more correctly, the dataset with timestamp=t).
c) Filters which support temporal activity (exporting more than one dataset) as in b) above can have their output dataobjects replaced by the executive and fill the N steps as before. We replace the code in the existing CheckDataObject() method which currently is incorrect (temporal IsA(composite) always returns true and causes untold trouble) and solve most of the outstanding temporal problems in one place (almost). Effectively we have, if filter supports temporal output and more than one steps were requested. change it - . If filter requires temporal and only one step exists, create temporal - the rest of the time, stop messing about. The current dataset swapping logic is a mess.
d) existing filters(readers mainly) can be updated to support temporal natively with a pretty simple strategy. Add the temporal support flag, and in request data, generate N steps if required, and place them in the output. Much easier than the current option of creating a new class derived from TemporalDataSetAlgorithm and instantiating a reader inside it. (I'm talking here about generating multiple time steps from an existing reader - the executive can loop for you, but if you have a sophisticated file format, reading N at once can be desirable...)
The changes the users will notice are
vtkTemporalDataSetAlgorithm is removed, instead, filters which can supply multiple steps place an extra key TEMPORAL_OUTPUT_SUPPORTED in FillOutputInformation
Filters which require multiple timesteps will place TEMPORAL_INPUT_REQUIRED during the FillInputInformation call. (Here' I think we might enhance the paraview GUI to allow a temporal input domain so that you can only instantiate temporal filters when connected to filters which are capable of supplying it). Filters such as temporal interpolator, become dataobject algorithms, likewise temporalcache.
I believe this will solve a great many problems, though I have not considered the effect on TEMPORAL_FAST_PATH so please get back to me if this is going to be a problem. |
|
|
|
(0037559)
|
|
Kitware Robot
|
|
2016-08-12 09:57
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current ParaView Issues page linked in the banner at the top of this page. |
|