<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 20, 2015 at 5:24 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="">
    <br>
    <br>
    <div>On 20/07/15 22:51, Matthew Knepley
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div>Thats a bug. CreateGhostCells() makes an entirely new
              DM, and the SetNatural is a piece of state which did not
              get carried over. I will</div>
            <div>fix it.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    OK, that's what I suspected. Thanks.<span class=""><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>I have a question about this strategy. The design
              philosophy for the PETSc discretization stuff is to make
              as much</div>
            <div>mesh-independent as possible. I usually think of
              boundary and initial conditions as analytic functions that
              are</div>
            <div>applied to a given geometric region on the mesh, and
              then projected into a function space once I choose my</div>
            <div>discretization. Why doesn't that work in this case?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Yeah, I noticed that's the way all the example problems work, and
    I'd do it that way too if I could.<br>
    <br>
    However my initial conditions aren't defined by analytic functions.
    Often they are taken from the end result of a previous model run, so
    they're defined as values on particular cells. In most such cases I
    should be able to load them in from HDF5 files, but even then I
    gather I'll still need this natural ordering stuff to make them end
    up on the right cells in the mesh, especially as the number of
    processors won't necessarily be the same between runs.</div></blockquote><div><br></div><div>It is really seductive to view the solution as a bunch of FEM coefficients, but I think that destroys code modularity. I would rather</div><div>endure (at least in the short term) the overhead of point location and represent my solution as a real function, than hope that I am</div><div>using exactly the same mesh/discretization the next time around and have to do parallel fixups like this.</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"><span class=""><br>
    - Adrian<br>
    <pre cols="72">-- 
Dr Adrian Croucher
Senior Research Fellow
Department of Engineering Science
University of Auckland, New Zealand
email: <a href="mailto:a.croucher@auckland.ac.nz" target="_blank">a.croucher@auckland.ac.nz</a>
tel: +64 (0)9 923 84611
</pre>
  </span></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">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></div>