<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Ah, okay. To confirm, you have a DM that you are solving for, and in its user context, you have several other DMs, each with a Vec, describing the "problem data" like coefficients, forcing terms, and internal discontinuities? </div>
</div>
</div>
</blockquote>
Yes, but because of the structure of my problem, the application context also contains a link to the original DM.</div>
<div>Think solving F(u,v) = 0 where and v don't have the same layout, or the same dimensionality, without field split.</div>
<div>My iterate is </div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>u_{n+1} = argmin_w F(w,v_n)</div>
<div> <span class="Apple-tab-span" style="white-space:pre"> </span>v_{n+1} = argmin_w F(u_{n+1},w)</div>
<div>The DM associated with u is DMu and the one with v is DMv</div>
<div>For the application context, I can either a create AppCtx with components (pointer to u, pointer to v, pointed to DMu, pointer to DMu), or</div>
<div>AppCtxu with components (pointer to v, pointer to DMv) and AppCtxv with components (pointer to u, pointer to DMu)</div>
<div>In this setting, is calling SNESSolve with Vec u and Application Context AppCtx legal, or do I have to use AppCtxu / AppCtxv? </div>
<div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div>That is completely fine, and not "aliasing", but it does not play well with <i>
geometric</i> multigrid because coarse grids reference the same application context. We have a system of hooks for managing such resolution-dependent data, though only with a C interface so far. (We needed this to get geometric multigrid and FAS to work with
TS. Most non-toy applications need it too.)</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Can you point me to an example? Are interfaces C only because nobody has ever needed fortran versions, or is there a technical reason.</div>
<br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I'm not sure if there is a way to make this easier. We have been using PetscObjectCompose() to attach things to the DM on different levels. We could have a slightly friendlier "user" interface for that.</div>
</div>
</div>
</blockquote>
<div>I debated AppCtx vs. ObjectCompose for quite a bit. As far as I understand, PetscCompose/Query uses object names to reference objects, so I would have ended passing the name of the coefficients DM and Vecs in the appctx. I opted to put pointers to them
in the appctx instead of names. It looked a bit simpler at the time. Now I have two good reasons I should have gone the PetscObject way. Oh well...</div>
<br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>So keeping those things in the app context is just fine, but if you want to use geometric multigrid, you'll have to take them out of the app context and put them in a different structure attached to the DM that is not transparently propagated under coarsening
and refinement. If you think you might do this eventually, I recommend commenting/organizing your app context so that resolution-dependent stuff is easily identifiable.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I had not thought about it, but it is quite feasible. I store all coefficients that are constant per block of cells or Dof in PetscBags, and everything that has variation at the scale of the finite element space in Vecs. How would the creation of the
coarse DMs be handled, though? The geometry part is trivial to propagate using DMClone, but you may need to user feedback for the data layout part, unless you have a scheme that describes it (i.e. for this IS of cells, n dof at the vertices, p at the faces
etc)</div>
<div><br>
</div>
<div><br>
</div>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div>
<div>
<div>
<div class="im">
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
<div>
<div class="im">
<blockquote type="cite">
<div>
<div class="gmail_extra">I don't mind that, but can't you have an index set describing the codim 0 elements (maybe all of them) and another index set for the codim 1 elements on the features you care about? You can take their union (or concatenate) for your
assembly loop if you like. Is there something wrong with this approach?</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</div>
<div>Thats a very good point. In the end it doesn't really matter. As far as I remember, the main reason I ended with my current scheme is that DMMesh did not play well with partially interpolated meshes. I don't know what the current status of DMComplex is. </div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">Okay, I think it's important to eventually support partially interpolated meshes to avoid using a lot of memory when used with low-order discretizations. I see no reason why there can't also be a direct cache for closure. For a P1 basis,
that amounts to a point range</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">[cells, boundary faces, vertices]</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">closure: [cells -> vertices, faces -> vertices]</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">So cell -> face need not be stored anywhere. Presumably there is a reason why Matt didn't write it this way. Is it just uniformity of data structure?</div>
</blockquote>
</div>
<div><br>
</div>
<div>Do we mean the same by partially interpolated mesh? What I mean is a mesh the only faces that are explicitly stored are the one we are interested in (typically the boundary mesh). For P1 elements, we need only to know of [cells, some faces, vertices]. I
tried to manually build partially interpolated sieves with only some of the faces, and distribution would fail. That's how I ended up with a mix of cells of co-dimension 0 and 1. If one wants access to ALL faces / edges or none of them, there is no problem
in the current implementation.</div>
<div><br>
</div>
<div>Blaise </div>
<div><span style="font-size: 12px; "><br>
</span></div>
<div><span style="font-size: 12px; "><br>
</span></div>
<div><span style="font-size: 12px; ">-- </span></div>
<div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; font-size: 12px; border-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">
Department of Mathematics and Center for Computation & Technology</div>
<div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">
Louisiana State University, Baton Rouge, LA 70803, USA</div>
<div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">
Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 <a href="http://www.math.lsu.edu/~bourdin">
http://www.math.lsu.edu/~bourdin</a></div>
<div><br class="khtml-block-placeholder">
</div>
<div><br class="khtml-block-placeholder">
</div>
<br class="Apple-interchange-newline">
</div>
</span></div>
</span><br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline">
</span><br class="Apple-interchange-newline">
</div>
<br>
</body>
</html>