Re: [Paraview] structured to unstructured when using multiblocks filter
Hi Ufuk,
If the files are small, could you send them? I'll investigate some. Also,
sending your Catalyst Python script may help clue me into what's going
wrong.
Best,
Andy
On Mon, Mar 19, 2018 at 4:06 PM, Ufuk Turuncoglu <
u.utku.turunco...@be.itu.edu.tr> wrote:
> Thanks for your valuable comments. Yes, for each model component has two
> grid 2d and 3d and they are coming from different channels. It is working
> under 5.4.1 but i'll check the bug and try to fix my version until 5.5
> released. BTW, even if I set whole extend (to test it I hardcoded it) in
> the place that you indicate, the piece and whole extent is same in the
> files.
>
> Regards,
>
> --ufuk
>
>
> --
> *From: *"Andy Bauer" <andy.ba...@kitware.com>
> *To: *"Ufuk Utku Turuncoglu (BE)" <u.utku.turunco...@be.itu.edu.tr>
> *Cc: *"paraview" <parav...@paraview.org>
> *Sent: *Monday, March 19, 2018 3:51:51 PM
> *Subject: *Re: [Paraview] structured to unstructured when using
> multiblocks filter
>
> Hi Ufuk,
>
> It looks like you're already using multi-channel input as you're adding
> since you have " g_coprocessorData->AddInput(strarr[i]); " unless that's
> always just called once. We're just trying to clarify the "inputs" by
> naming them channels -- I'm not sure it makes it easier to understand but
> it makes it easier to talk about with others that understand that concept
> in Catalyst.
>
> Setting whole extent would look like the following at line 129 in
> adaptor.cpp:
> if (vtkDataSet* grid = vtkDataSet::SafeDownCast(g_coprocessorData->
> GetInputDescriptionByName(name)->GetGrid())) {
> ParaViewCoProcessing::ClearFieldDataFromGrid(grid);
> g_coprocessorData->GetInputDescriptionByName(name)-> SetWholeExtent(ilow,
> ihigh, jlow, jhigh, klow, khigh);
> } else {
>
> Here, *low and *high are global values. For example, for a 1D case if each
> process has 5 points and you have 3 mpi processes
> ilow=jlow=jhigh=klow=khigh=0 and ihigh=12. The
> vtkStructuredGrid::SetExtent() would look like:
> proc 0: 0, 4, 0, 0, 0, 0
> proc 1: 4, 8, 0, 0, 0, 0
> proc 2: 8, 12, 0, 0, 0, 0
>
> This looks like you're doing it properly in grid.cpp though but I didn't
> set the SetWholeExtent() in adaptor.cpp and I'm guessing that's what's
> missing.
>
> The multi-channel input should work in 5.4.1 but I found a bug that's been
> fixed in the upcoming 5.5 that was affecting Live. See
> https://gitlab.kitware.com/paraview/paraview/merge_requests/2212 for
> details on that. It's fairly small so you can probably backport that to
> your 5.4.1 build if you're more comfortable using 5.4.1.
>
> Cheers,
> Andy
>
> On Mon, Mar 19, 2018 at 7:50 AM, Ufuk Utku Turuncoglu (BE) <
> u.utku.turunco...@be.itu.edu.tr> wrote:
>
>> 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
Re: [Paraview] structured to unstructured when using multiblocks filter
Hi Ufuk,
It looks like you're already using multi-channel input as you're adding
since you have " g_coprocessorData->AddInput(strarr[i]); " unless that's
always just called once. We're just trying to clarify the "inputs" by
naming them channels -- I'm not sure it makes it easier to understand but
it makes it easier to talk about with others that understand that concept
in Catalyst.
Setting whole extent would look like the following at line 129 in
adaptor.cpp:
if (vtkDataSet* grid = vtkDataSet::SafeDownCast(g_coprocessorData->
GetInputDescriptionByName(name)->GetGrid())) {
ParaViewCoProcessing::ClearFieldDataFromGrid(grid);
g_coprocessorData->GetInputDescriptionByName(name)-> SetWholeExtent(ilow,
ihigh, jlow, jhigh, klow, khigh);
} else {
Here, *low and *high are global values. For example, for a 1D case if each
process has 5 points and you have 3 mpi processes
ilow=jlow=jhigh=klow=khigh=0 and ihigh=12. The
vtkStructuredGrid::SetExtent() would look like:
proc 0: 0, 4, 0, 0, 0, 0
proc 1: 4, 8, 0, 0, 0, 0
proc 2: 8, 12, 0, 0, 0, 0
This looks like you're doing it properly in grid.cpp though but I didn't
set the SetWholeExtent() in adaptor.cpp and I'm guessing that's what's
missing.
The multi-channel input should work in 5.4.1 but I found a bug that's been
fixed in the upcoming 5.5 that was affecting Live. See
https://gitlab.kitware.com/paraview/paraview/merge_requests/2212 for
details on that. It's fairly small so you can probably backport that to
your 5.4.1 build if you're more comfortable using 5.4.1.
Cheers,
Andy
On Mon, Mar 19, 2018 at 7:50 AM, Ufuk Utku Turuncoglu (BE) <
u.utku.turunco...@be.itu.edu.tr> wrote:
> 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> 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
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages
Re: [Paraview] structured to unstructured when using multiblocks filter
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> 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 > > 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 > > ___ 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
[Paraview] structured to unstructured when using multiblocks filter
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 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
