<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 25, 2014 at 6:02 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">
On Fri, Apr 25, 2014 at 6:03 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Fri, Apr 25, 2014 at 2:47 PM, Mark Lohry <<a href="mailto:mlohry@gmail.com">mlohry@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> Jed and I have discussed this. DMComposite is really not great for even<br>
> moderate numbers of blocks because it serializes. Also, the real performance<br>
> advantage of structured blocks is saturated by a small number of structured<br>
> cells (32 or so), and thus large structured pieces do not make a lot of<br>
> sense<br>
> (this is the same intuition behind the performance of spectral elements).<br>
<br>
Huh? Perhaps this is the case in finite elements, but in FV you see<br>
great performance (and accuracy vs nDOFs) benefits from relatively<br>
large structured blocks in conjunction with FAS multigrid. As a visual<br>
aid, I'm thinking of meshes like this which have on the order of 64^3<br>
- 128^3 cells:<br>
<a href="http://spitfire.princeton.edu/mesh3.png" target="_blank">http://spitfire.princeton.edu/mesh3.png</a></blockquote><div><br></div><div>I need to clarify. I am sure you see great performance from a large structured mesh.</div>
<div>However, that performance comes from good vectorization and decent blocking for</div><div>the loads. Thus it will not decrease if you made your structured pieces smaller. You</div><div>can do FAS on unstructured meshes just fine (we have an example in PETSc). The</div>
<div>coarsest meshes would not be structured, but the performance is not a big issue</div><div>there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Our<br>
> recommendation is to have a coarse unstructured mesh with regular refinement<br>
> inside each coarse cell. This is something we could really support well. Its<br>
> not all there yet, but we have all the pieces.<br>
><br>
<br>
Would you still be able to exchange the fine-mesh data across block<br>
boundaries? That would be essential.<br></blockquote><div><br></div><div>There would be no blocks, so yes that would be easy.</div><div><br></div><div>  Thanks,</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">

>><br>
>> 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>
><br>
><br>
> There is Overture.<br>
><br>
>    Matt<br>
><br>
<br>
<br>
Fair enough, thanks. For the time being it looks like I'll have to<br>
proceed by managing all the parallelization/message passing internally<br>
and manually filling in petsc vectors for the various solvers.<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>