<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 14. Aug. 2019 um 20:15 Uhr schrieb Jed Brown via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov">petsc-dev@mcs.anl.gov</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
<br>
> On Wed, Aug 14, 2019 at 11:46 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
>><br>
>> > On Tue, Aug 13, 2019 at 7:35 PM Stefano Zampini <<br>
>> <a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>><br>
>> > wrote:<br>
>> ><br>
>> >><br>
>> >><br>
>> >> On Aug 14, 2019, at 1:19 AM, Jed Brown via petsc-dev <<br>
>> >> <a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
>> >><br>
>> >> [Cc: petsc-dev]<br>
>> >><br>
>> >> Also, why is our current mode of localized coordinates preferred over<br>
>> >> the coordinate DM being non-periodic? Is the intent to preserve that<br>
>> >> for every point in a DM, the point is also valid in the coordinate DM?<br>
>> >><br>
>> >> Yes.<br>
>> ><br>
>> >> Can there be "gaps" in a chart?<br>
>> >><br>
>> >> Yes.<br>
>> ><br>
>> >> I've been digging around in the implementation because there is no<br>
>> >> documentation of localized coordinates, but it feels more complicated<br>
>> >> than I'd have hoped.<br>
>> >><br>
>> >><br>
>> >> A while ago, “localization” of coordinates was supporting only very<br>
>> simple<br>
>> >> cases, where periodic points were identified though the ‘maxCell’<br>
>> parameter<br>
>> >> (used to compute the proper cell coordinates). I think this is the<br>
>> reason<br>
>> >> why you need at least 3 cells to support periodicity, since the BoxMesh<br>
>> >> constructor uses the maxCell trick.<br>
>> >><br>
>> ><br>
>> > This was my original conception since it was the only fully automatic way<br>
>> > to apply periodicity on an unstructured mesh that<br>
>> > was read from a file or generator.<br>
>><br>
>> I take it this is in reference to this logic.<br>
>><br>
>> PetscErrorCode DMLocalizeCoordinateReal_Internal(DM dm, PetscInt dim,<br>
>> const PetscReal anchor[], const PetscReal in[], PetscReal out[])<br>
>> {<br>
>> PetscInt d;<br>
>><br>
>> PetscFunctionBegin;<br>
>> if (!dm->maxCell) {<br>
>> for (d = 0; d < dim; ++d) out[d] = in[d];<br>
>> } else {<br>
>> for (d = 0; d < dim; ++d) {<br>
>> if ((dm->bdtype[d] != DM_BOUNDARY_NONE) && (PetscAbsReal(anchor[d] -<br>
>> in[d]) > dm->maxCell[d])) {<br>
>> out[d] = anchor[d] > in[d] ? dm->L[d] + in[d] : in[d] - dm->L[d];<br>
>> } else {<br>
>> out[d] = in[d];<br>
>> }<br>
>> }<br>
>> }<br>
>> PetscFunctionReturn(0);<br>
>> }<br>
>><br>
>><br>
>> This implies that the mesh be aligned to coordinates (at least in the<br>
>> periodic dimension)<br>
><br>
><br>
> No, it does not. That is the point, that you can have edges crossing the<br>
> periodic boundary.<br>
<br>
I mean that u(x) = u(x+(L,0)) rather than u(x) = u(x+v) where ||v||=L is<br>
arbitrary.<br>
<br>
>> An (unstructured) mesh generator has to support periodicity anyway to<br>
>> generate a mesh with that topology.<br>
><br>
> Or you can fake it.<br>
<br>
How would you handle a different number/distribution of points on<br>
surfaces that are meant to be joined periodically?<br>
<br>
>> >> The DMPlex code fully support coordinates localized only in those cells<br>
>> >> touching the periodic boundary. (I’m not a fan of this, since it<br>
>> requires a<br>
>> >> lot of ‘if’ ‘else’ switches )<br>
>> >><br>
>> ><br>
>> > I believe that Lisandro wanted this to cut down on redundant storage of<br>
>> > coordinates.<br>
>><br>
>> What was the rationale for having these special cells with<br>
>> localized/DG-style coordinates versus storing coordinates as a<br>
>> non-periodic continuous field?<br>
><br>
><br>
> I do not understand what you mean.<br>
><br>
><br>
>> The local points could be distinct for<br>
>> both fields and coordinates, with the global SF de-duplicating the<br>
>> periodic points for fields, versus leaving them distinct for<br>
>> coordinates.<br>
><br>
><br>
> Oh, no I would never do that.<br>
<br>
Can you help me understand why that model is bad?<br></blockquote><div><br></div><div>I'm also interested in the answer to this question, because I am considering something similar for DMStag; if DM has a periodic BC, the corresponding coordinate DM has a "none" BC, so the boundary points are duplicated - this would hopefully make it much easier to locate particles in elements.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
>> (Global coordinates are often not used.) It seems like a<br>
>> simpler model to me, and would eliminate a lot of if/else statements,<br>
>> but you've been thinking about this more than me.<br>
>><br>
>> >> I think domain_box_size 1 is not possible, we can probably allow<br>
>> >> domain_box_size 2.<br>
>> >><br>
>> ><br>
>> > Technically, now a single box is possible with higher order coordinate<br>
>> > spaces, but you have to do everything by hand<br>
>> > and it completely untested.<br>
>><br>
>> Why would higher order coordinate spaces be needed? I could localize<br>
>> coordinates for all cells.<br>
>><br>
><br>
> I mean if you wanted a single cell that was periodic, you could do that<br>
> with higher order coordinates.<br>
<br>
But it would also work with linear coordinates, no? (Assume the user<br>
localizes their own coordinates.)<br>
</blockquote></div></div>