<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><div class="moz-cite-prefix">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.<br></div><div class="moz-cite-prefix"><br></div><div class="moz-cite-prefix">Regards,</div><div class="moz-cite-prefix"><br></div><div class="moz-cite-prefix">--ufuk</div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>From: </b>"Andy Bauer" <andy.bauer@kitware.com><br><b>To: </b>"Ufuk Utku Turuncoglu (BE)" <u.utku.turuncoglu@be.itu.edu.tr><br><b>Cc: </b>"paraview" <paraview@paraview.org><br><b>Sent: </b>Monday, March 19, 2018 3:51:51 PM<br><b>Subject: </b>Re: [Paraview] structured to unstructured when using multiblocks filter<br></div><br><div data-marker="__QUOTED_TEXT__"><div dir="ltr"><div><div><div><div>Hi Ufuk,<br><br></div>It looks like you're already using multi-channel input as you're adding since you have "
g_coprocessorData-><span class="gmail-pl-c1">AddInput</span>(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.<br><br></div>Setting whole extent would look like the following at line 129 in adaptor.cpp:<br>
<table class="gmail-highlight gmail-tab-size gmail-js-file-line-container"><tbody><tr><td id="gmail-LC128" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line">    <span class="gmail-pl-k">if</span> (vtkDataSet* grid = <span class="gmail-pl-c1">vtkDataSet::SafeDownCast</span>(g_coprocessorData-><span class="gmail-pl-c1">GetInputDescriptionByName</span>(name)-><span class="gmail-pl-c1">GetGrid</span>())) {</td>
      </tr>
      <tr>
        </tr></tbody></table><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container"><tbody><tr><td id="gmail-LC129" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line gmail-highlighted">      <span class="gmail-pl-c1">ParaViewCoProcessing::ClearFieldDataFromGrid</span>(grid);<br>
g_coprocessorData-><span class="gmail-pl-c1">GetInputDescriptionByName</span>(name)-><span class="gmail-pl-c1"></span>

SetWholeExtent(ilow, ihigh, jlow, jhigh, klow, khigh);<br></td>
      </tr>
      <tr>
        </tr></tbody></table><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container"><tbody><tr><td id="gmail-LC130" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line">    } <span class="gmail-pl-k">else</span> {</td>
      </tr>
      <tr>
        </tr></tbody></table>

<br></div>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:<br></div>proc 0: 0, 4, 0, 0, 0, 0<br><div><div>
proc 1: 4, 8, 0, 0, 0, 0 <br>
proc 2: 8, 12, 0, 0, 0, 0

<br><br></div><div>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.<br><br></div><div>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 <a href="https://gitlab.kitware.com/paraview/paraview/merge_requests/2212" target="_blank">https://gitlab.kitware.com/paraview/paraview/merge_requests/2212</a> 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.<br><br></div><div>Cheers,<br></div><div>Andy<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 19, 2018 at 7:50 AM, Ufuk Utku Turuncoglu (BE) <span dir="ltr"><<a href="mailto:u.utku.turuncoglu@be.itu.edu.tr" target="_blank">u.utku.turuncoglu@be.itu.edu.tr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;" data-mce-style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
  
    
  
  <div>
    <div class="m_7908305580367046430moz-cite-prefix">Hi Andy,</div>
    <div class="m_7908305580367046430moz-cite-prefix"><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix">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),</div>
    <div class="m_7908305580367046430moz-cite-prefix"><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix"><a class="m_7908305580367046430moz-txt-link-freetext" href="https://github.com/uturuncoglu/RegESM/tree/master/cop" target="_blank">https://github.com/uturuncoglu/RegESM/tree/master/cop</a><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix"><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix">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?</div>
    <div class="m_7908305580367046430moz-cite-prefix"><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix">Regards,</div>
    <div class="m_7908305580367046430moz-cite-prefix"><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix">--ufuk<br>
    </div><div><div class="h5">
    <div class="m_7908305580367046430moz-cite-prefix"><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix"><br>
    </div>
    <div class="m_7908305580367046430moz-cite-prefix">On 19.03.2018 13:36, Andy Bauer wrote:<br>
    </div>
    <blockquote>
      <div dir="ltr">
        <div>
          <div>Hi Ufuk,<br>
            <br>
          </div>
          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(). <br>
          <br>
        </div>
        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.<br>
        <div><br>
        </div>
        <div>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.<br>
        </div>
        <div><br>
          Note that the multiblock/multipiece hierarchy will be
          undergoing a significant change in the near future.<br>
          <br>
        </div>
        <div>Best,<br>
        </div>
        <div>Andy<br>
        </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sun, Mar 18, 2018 at 1:21 PM, Ufuk
          Turuncoglu <span dir="ltr"><<a href="mailto:u.utku.turuncoglu@be.itu.edu.tr" target="_blank">u.utku.turuncoglu@be.itu.edu.tr</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;" data-mce-style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
            <div>
              <div style="font-family: arial,helvetica,sans-serif; font-size: 12pt; color: #000000;" data-mce-style="font-family: arial,helvetica,sans-serif; font-size: 12pt; color: #000000;">
                <div>Hi, <br>
                  <br>
                  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. <br>
                  <br>
                  Regards, <br>
                  <br>
                  --ufuk</div>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
            <br>
            Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
            <br>
            Please keep messages on-topic and check the ParaView Wiki
            at: <a href="http://paraview.org/Wiki/ParaView" rel="noreferrer" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
            <br>
            Search the list archives at: <a href="http://markmail.org/search/?q=ParaView" rel="noreferrer" target="_blank">http://markmail.org/search/?q=ParaView</a><br>
            <br>
            Follow this link to subscribe/unsubscribe:<br>
            <a href="https://public.kitware.com/mailman/listinfo/paraview" rel="noreferrer" target="_blank">https://public.kitware.com/mailman/listinfo/paraview</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <p><br>
    </p>
  </div></div></div>

</blockquote></div></div><br></div></div></body></html>