<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 20, 2017 at 10:41 PM, Adrian Croucher <span dir="ltr"><<a href="mailto:a.croucher@auckland.ac.nz" target="_blank">a.croucher@auckland.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div class="m_3568675152172340888moz-cite-prefix">On 16/06/17 11:37, Adrian Croucher
wrote:<br>
</div>
<blockquote type="cite">
<div class="m_3568675152172340888moz-cite-prefix">On 16/06/17 01:19, Matthew Knepley
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for those ideas, very helpful.<br>
<br>
If I try this approach (forming whole Jacobian matrix
and using PCFieldSplit Schur), I guess I will first need
to set up a modified DMPlex for the whole fracture +
matrix mesh- so I can use it to create vectors and the
Jacobian matrix (with the right sparsity pattern), and
also to work out the coloring for finite differencing.<br>
<br>
Would that be straight-forward to do? Currently my DM
just comes from DMPlexCreateFromFile(). Presumably you
can use DMPlexInsertCone() or similar to add points into
it?</blockquote>
<div><br>
</div>
<div>You can certainly modify the mesh. I need to get a
better idea what kind of modification, and then</div>
<div>I can suggest a way to do it. What do you start with,
and what exactly do you want to add?</div>
<div><br>
</div>
<br>
</div>
</div>
</div>
</blockquote>
The way dual porosity is normally implemented in a finite volume
context is to add an extra matrix rock cell 'inside' each of the
original cells (which now represent the fractures, and have their
volumes reduced accordingly), with a connection between the
fracture cell and its corresponding matrix rock cell, so fluid can
flow between them.<br>
<br>
More generally there can be multiple matrix rock cells for each
fracture cell, in which case further matrix rock cells are nested
inside the first one, again with connections between them. There
are formulae for computing the appropriate effective matrix rock
cell volumes and connection areas, typically based on a 'fracture
spacing' parameter which determines how fractured the rock is.<br>
<br>
So in a DMPlex context it would mean somehow adding extra DAG
points representing the internal cells and faces for each of the
original cells. I'm not sure how that would be done.<br>
</blockquote>
<br></span>
I've been having a go at this- copying the cones and supports from
the original DM into a new DM, which will represent the topology of
the dual porosity mesh, but adding one new cell for each original
cell, and a face connecting the two. I've based my attempt loosely
on some of the stuff in SplitFaces() in TS ex11.c.<br>
<br>
It isn't working though, as yet- when I construct the new DM and
view it, the numbers of cells, faces etc. don't make sense, and the
depth label says it's got 7 strata, where it should still just have
4 like the original DM.<br>
<br>
I may have just messed it up somehow, but it occurred to me that
maybe DMPlex won't like having bits of its DAG having different
depths? With what I've been trying, the dual porosity parts of the
mesh would just specify DAG points representing the new cells and
the corresponding faces, but not for any edges or vertices of those
faces. I hoped that would be sufficient for generating the nonzero
structure of the Jacobian matrix. But I don't know if DMPlex will
allow a DAG like that?<br></div></blockquote><div><br></div><div>I was going to write you, but I am moving houses and its very hectic.</div><div><br></div><div>From the above description, its not clear to me that you want this topology. For example, in the case that each cell gets an internal cell,</div><div>it seems like you could just handle this in the function space for each cell. Even for multiple internal cells, it seems like function space</div><div>parameterization is a better option. Topology is supposed to indicate the support of basis functions, but here that job is done. I would</div><div>just treat it as some sort of augmented approximation space.</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"><div bgcolor="#FFFFFF" text="#000000">
- Adrian<br>
<pre class="m_3568675152172340888moz-signature" cols="72"><span class="">--
Dr Adrian Croucher
Senior Research Fellow
Department of Engineering Science
University of Auckland, New Zealand
email: <a class="m_3568675152172340888moz-txt-link-abbreviated" href="mailto:a.croucher@auckland.ac.nz" target="_blank">a.croucher@auckland.ac.nz</a></span>
tel: <a href="tel:+64%209-923%204611" value="+6499234611" target="_blank">+64 (0)9 923 4611</a>
</pre>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><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.caam.rice.edu/~mk51/" target="_blank">http://www.caam.rice.edu/~mk51/</a><br></div></div></div>
</div></div>