<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 25, 2014 at 2:47 PM, Mark Lohry <span dir="ltr"><<a href="mailto:mlohry@gmail.com" target="_blank">mlohry@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Most common use case would be from 1 to 15 blocks or so, although I<br>
have occasionally seen need for 100+. This also brings to mind a<br>
question I had about more general connectivity in single-block domains<br>
like a C-mesh, where you have halo dependencies to itself that are not<br>
simply "periodic."<br></blockquote><div><br></div><div>Jed and I have discussed this. DMComposite is really not great for even</div><div>moderate numbers of blocks because it serializes. Also, the real performance</div>
<div>advantage of structured blocks is saturated by a small number of structured</div><div>cells (32 or so), and thus large structured pieces do not make a lot of sense</div><div>(this is the same intuition behind the performance of spectral elements). Our</div>
<div>recommendation is to have a coarse unstructured mesh with regular refinement</div><div>inside each coarse cell. This is something we could really support well. Its</div><div>not all there yet, but we have all the pieces.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As far as the difficult task of setting up the communication, is that<br>
even possible to do manually without treating everything as fully<br>
unstructured? What other packages are out there for multi block<br>
structured domains?<br></blockquote><div><br></div><div>There is Overture.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Fri, Apr 25, 2014 at 2:40 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>   Mark,<br>
><br>
>    Are you thinking of the case of two or three (or so blocks) or are you thinking of many blocks?<br>
><br>
>    DMComposite helps with multiple DM’s but unfortunately does not do the difficult task of setting up the communication of data between the different block boundaries.<br>
><br>
>     There are some other packages out there for multi block domains that might be better for your case thus I ask about your particular situation and what you need.<br>
><br>
>    Barry<br>
><br>
> On Apr 25, 2014, at 1:31 PM, Mark Lohry <<a href="mailto:mlohry@gmail.com">mlohry@gmail.com</a>> wrote:<br>
><br>
>> To resurrect this thread:<br>
>> <a href="https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2012-August/014930.html" target="_blank">https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2012-August/014930.html</a><br>
>><br>
>> Matt Knepley suggested the correct way to handle a structred<br>
>> multi-block mesh was to use DMComposite. I'm not seeing anything in<br>
>> the documentation about how to properly use DMComposite, however.<br>
>><br>
>> What are the necessary steps to go from a single-block code using DMDA<br>
>> to a multi-block code that handles all the appropriate data passing at<br>
>> block boundaries?<br>
><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>