<div dir="ltr"><div dir="ltr">On Mon, May 27, 2019 at 7:26 PM Adrian Croucher via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">hi<br>
<br>
A couple of years back I was asking questions here about implementing <br>
"dual porosity" finite volume methods via PETSc (in which flow in <br>
fractured media is represented by adding extra "matrix" cells nested <br>
inside the original mesh cells).<br>
<br>
At the time I was asking about how to solve the resulting linear <br>
equations more efficiently (I still haven't worked on that part of it <br>
yet, so at present it's still just using a naive linear solve which <br>
doesn't take advantage of the particular sparsity pattern), and about <br>
how to add the extra cells into the DMPlex mesh, which I figured out how <br>
to do.<br>
<br>
It is working OK except that strong scaling performance is not very <br>
good, if dual porosity is applied over only part of the mesh. I think <br>
the reason is that I read the mesh in and distribute it, then add the <br>
dual porosity cells in parallel on each process. So some processes can <br>
end up with more cells than others, in which case the load balancing is bad.<br>
<br>
I'm considering trying to change it so that I add the dual porosity <br>
cells to the DMPlex in serial, before distribution, to regain decent <br>
load balancing.<br></blockquote><div><br></div><div>I would not do that. It should be much easier, and better from a workflow standpoint,</div><div>to just redistribute in parallel. We now have several test examples that redistribute</div><div>in parallel, for example</div><div><br></div><div>  <a href="https://bitbucket.org/petsc/petsc/src/cd762eb66180d8d1fcc3950bd19a3c1b423f4f20/src/dm/impls/plex/examples/tests/ex1.c#lines-486">https://bitbucket.org/petsc/petsc/src/cd762eb66180d8d1fcc3950bd19a3c1b423f4f20/src/dm/impls/plex/examples/tests/ex1.c#lines-486</a></div><div><br></div><div>Let us know if you have problems.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To do that, I'd also need to compute the cell centroids in serial (as <br>
they are often used to identify which cells should have dual porosity <br>
applied), using DMPlexComputeGeometryFVM(). The geometry vectors would <br>
then have to be distributed later, I guess using something like <br>
DMPlexDistributeField().<br>
<br>
Should I expect a significant performance hit from calling <br>
DMPlexComputeGeometryFVM() on the serial mesh compared with doing it (as <br>
now) on the distributed mesh? It will increase the serial fraction of <br>
the code but as it's only done once at the start I'm hoping the benefits <br>
will outweigh the costs.<br>
<br>
- Adrian<br>
<br>
-- <br>
Dr Adrian Croucher<br>
Senior Research Fellow<br>
Department of Engineering Science<br>
University of Auckland, New Zealand<br>
<a href="mailto:email%3Aa.croucher@auckland.ac.nz" target="_blank">email:a.croucher@auckland.ac.nz</a><br>
tel: +64 (0)9 923 4611<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>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><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>