Utkarsh,
I agree that composite readers (and probably other composite filters)
can provide the dataset structure in the RequestDataObject pass, but I
don't know that many currently do. Certainly the ExodusIIReader
doesn't. It would be easy enough to provide an empty hierarchy of *all
the available* blocks the file(s) contain, but doing that with all of
the block/set selections plus populating empty arrays on each leaf
(which I think would be useful) would be a lot of work.
David
On Jun 1, 2011, at 13:33 , Utkarsh Ayachit wrote:
Dave,
Output types become a problem only for composite-datasets, for others
data-types are known after RequestDataObject pass which happens before
RequestData(). I am still not sure how (or if) to deal with composite
datasets in this case. We can expect the reader to give meta-data for
composite datasets and leaves in the dataset in more details as well,
but I am not sure we need to yet.
As far as the scalars/vectors/tensors go, no filter in paraview
requires active-scalars/tensors etc, it just checks for existence of
array with a give number of components. The meta-data should indeed
contain information about arrays and number of components.
Utkarsh
On Wed, Jun 1, 2011 at 4:09 PM, David Thompson <dcth...@sandia.gov>
wrote:
I like the idea. One possible problem that comes to mind is
filters that
produce different output types based on the input. Will enough of
the
metadata be passed through the pipeline before Execute() is called
for those
filters to hint at their output type? Otherwise, you'll be forced
to hit
Execute before adding any more filters.
Or, for that matter, what about filters which are disabled in the
menu when
there is no scalar/vector/tensor data on their input?
David
On Jun 1, 2011, at 12:30 , Utkarsh Ayachit wrote:
Folks,
I have been investigating the ability to create pipelines in
ParaView
without having to hit Apply at every single stage in the pipeline.
This would make it much easier to deal with really large data in a
usage scenario where the scientist is fairly familiar with the
visualization pipeline he's interested in setting up.
Following the recent changes to the ParaView ServerManager, the
ServerManager level requirement that filters need to be updated
before
connecting has disappeared. However, we still need to "Apply" to
get
updated information about arrays etc.
After a couple on discussions with Berk and Dave, I've consolidated
the thoughts on a Wiki page. If any one has any thoughts to
share, it
would be great.
http://www.paraview.org/ParaView3/index.php/No-Apply_Mechanism_for_Creating_Pipelines
Note that this is merely a concept. We have no plans of
implementing
it in near future (3.12/4.0).
Utkarsh
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
