Hi Andy,
Thanks for your help. Yes, each tile has its own grid information. The
problem is that if i set whole extent in the adaptor side and write data
to disk using allinputsgridwrite.py, the whole extent is same with piece
extent. I am not sure what is going on in the background when live
visualization activated. If you want to look at it for possible problem,
the code is in following link (adaptor.cpp and grid.cpp),
https://github.com/uturuncoglu/RegESM/tree/master/cop
The second option is also worth to try but first i need to look at the
example. BTW, i am using 5.4.1. Do you think that the multi-channel
input also works with 5.4.1? How it is handled by Catalyst in live mode?
Do i have multiple visualization pipeline?
Regards,
--ufuk
On 19.03.2018 13:36, Andy Bauer wrote:
Hi Ufuk,
Currently a multipiece data set always has to be nested under a
multiblock dataset. This definitely seems like an unreasonable
limitation on a structured grid under a multipiece dataset but I
suspect we just haven't had the resources to put into making this work
properly. My suggestion would be to try just having your Catalyst
adaptor provide a structured grid directly, assuming you only have one
grid per mpi process, and then try volume rendering like that. If you
do this though, make sure to set the whole extent with
vtkCPInputDataDescription::SetWholeExtent().
A thought here -- instead of changing your adaptor to generate the
structured grid directly instead of a multipiece dataset, maybe create
a second "channel" through a second vtkCPInputDataDescription that
provides just a structured grid. This way you can provide both dataset
types as needed instead of having to modify code back and forth,
recompile, etc. to get different functionality. See the
Examples/Catalyst/CxxMultiChannelInputExample in the 5.5 source code
for some more details on this.
I can't remember if you were using the editions or just the full
ParaView Catalyst build but in 5.5 there will be a volume rendering
Catalyst addition.
Note that the multiblock/multipiece hierarchy will be undergoing a
significant change in the near future.
Best,
Andy
On Sun, Mar 18, 2018 at 1:21 PM, Ufuk Turuncoglu
<u.utku.turunco...@be.itu.edu.tr
<mailto:u.utku.turunco...@be.itu.edu.tr>> wrote:
Hi,
I am using MPI parallel code under Catalyst co-processing. In this
case, i am defining data by creating multi-block dataset and
putting multi-piece dataset into the first block (0). In this
case, each piece is defined as structured grid. The problem is
that, to create volume rendering, i need to use MergeBlocks filter
under ParaView but it changes data type from structured grid to
unstructured one. I just wonder that is there any way to merge
blocks without changing type? Programmable filter etc.? Another
workaround could be defining dataset without using multi block
under co-processing adaptor code. So, is it possible to represent
multi-piece data under co-processing without putting it into
multi-bloack dataset.
Regards,
--ufuk
_______________________________________________
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
<http://www.kitware.com/opensource/opensource.html>
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView <http://paraview.org/Wiki/ParaView>
Search the list archives at:
http://markmail.org/search/?q=ParaView
<http://markmail.org/search/?q=ParaView>
Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/paraview
<https://public.kitware.com/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
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
https://public.kitware.com/mailman/listinfo/paraview
