<div class="gmail_extra">On Mon, Apr 23, 2012 at 10:46 AM, David Fuentes <span dir="ltr"><<a href="mailto:fuentesdt@gmail.com" target="_blank">fuentesdt@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I have some existing libMesh code that I would like to use with this ex52 GPU code example.</div><div><br></div><div>I think it may be reasonable to use the existing code for setup of initial conditions and jacobian calc,</div>
<div>But then use the GPU residual calculation.</div><div><br></div><div>Where is the nodal degree of freedom stored in the "DM_Complex" data structure ?</div><div>I would like to setup the same dof ordering in the libMesh data structures.</div>
<div><br></div><div>I'm also a little unfamiliar with the terminology in the DM_Complex data structure,</div><div>what is being referred to by the "cones", "maxConeSize", and "coneOrientation" ? </div>
</blockquote><div><br></div><div>Okay, the DMComplex only stores topological information. The "cone" and "support" terminology is</div><div>from <a href="http://arxiv.org/abs/0908.4427">http://arxiv.org/abs/0908.4427</a>, and in the language of DAGs means in edges and out edges. In</div>
<div>the Hasse Diagram, from combinatorial topology, the in edges come from lower dimensional mesh</div><div>pieces that "cover" the given piece of the mesh. For instance, a cell is covered by its vertices, so</div>
<div>the cone of a cell can be its vertices. This can be made more involved by including edges and faces.</div><div><br></div><div>All the information for data layout is not in the DMComplex, but in the PetscSection object. This is just</div>
<div>a map between pieces of the mesh, like vertices, and degrees of freedom, which are offsets into a</div><div>PETSc Vec. All values are stored in Vecs. There is a convenience function for creating this layout with</div>
<div>FEM information</div><div><br></div><div> <a href="http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/305aed156be4/src/snes/examples/tutorials/ex52.c#l188">http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/305aed156be4/src/snes/examples/tutorials/ex52.c#l188</a></div>
<div><br></div><div>but you can dot it yourself using the PetscSection functions to match any LibMesh layout, and then call</div><div><br></div><div> <a href="http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/305aed156be4/src/snes/examples/tutorials/ex52.c#l189">http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/305aed156be4/src/snes/examples/tutorials/ex52.c#l189</a></div>
<div><br></div><div>Let me know if this makes sense. Also, I have started the variable coefficient stuff, but its not done yet.</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>Lastly,</div><div>Are there any data structures to pass spatially varying element-wise material parameters to the inner loop of the assembly?</div><div><br></div><div>for example, something like:</div>
<div><br></div><div>diff -r 58bb1a4e8a0d src/snes/examples/tutorials/ex52_integrateElement.cu</div><div>--- a/src/snes/examples/tutorials/ex52_integrateElement.cu Tue Mar 27 23:22:11 2012 -0500</div><div>+++ b/src/snes/examples/tutorials/ex52_integrateElement.cu Mon Apr 23 09:36:30 2012 -0500</div>
<div>@@ -3,8 +3,8 @@</div><div> </div><div> #include "ex52_gpu.h"</div><div> </div><div>-__device__ vecType f1_laplacian(float u[], vecType gradU[], int comp) {</div><div>- return gradU[comp];</div><div>+__device__ vecType f1_laplacian(float thermalconductivity, float u[], vecType gradU[], int comp) {</div>
<div>+ return thermalconductivity*gradU[comp];</div><div> }</div><div><br></div><div><br></div><div><br></div><div><br></div><div>Thanks,</div><div>David</div><div class="HOEnZb"><div class="h5"><div><br></div><div><br>
</div><div><br></div><div><br></div><div>
<br></div><div><br></div><div>On Mon, Apr 2, 2012 at 9:37 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Mar 28, 2012 at 6:42 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Mar 28, 2012 at 6:25 PM, David Fuentes <span dir="ltr"><<a href="mailto:fuentesdt@gmail.com" target="_blank">fuentesdt@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Yes. This would work. </div><div>I had trouble compiling in single precision using the some of the external package options I was using for double.</div></blockquote><div><br></div></div><div>Okay, getting on it now.</div>
</div></blockquote><div><br></div></div><div>Okay, I have tested using PetscReal=double with floats on the GPU. If you want doubles on the GPU, you can</div><div>currently change PETSc/FEM.py:434. I am deciding what the best way to specify this type is.</div>
<div><br></div><div> Thanks,</div><div><br></div></div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>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<br>
</div>