[petsc-users] ex52_integrateElement.cu

[Matthew Knepley]

On Mon, Apr 23, 2012 at 10:46 AM, David Fuentes <fuentesdt at gmail.com> wrote:

> I have some existing libMesh code that I would like to use with this ex52
> GPU code example.
>
> I think it may be reasonable to use the existing code for setup of initial
> conditions and jacobian calc,
> But then use the GPU residual calculation.
>
> Where is the nodal degree of freedom stored in the "DM_Complex" data
> structure  ?
> I would like to setup the same dof ordering in the libMesh data structures.
>
> I'm also a little unfamiliar with the terminology in the DM_Complex data
> structure,
> what is being referred to by the "cones", "maxConeSize", and
> "coneOrientation" ?
>

Okay, the DMComplex only stores topological information. The "cone" and
"support" terminology is
from http://arxiv.org/abs/0908.4427, and in the language of DAGs means in
edges and out edges. In
the Hasse Diagram, from combinatorial topology, the in edges come from
lower dimensional mesh
pieces that "cover" the given piece of the mesh. For instance, a cell is
covered by its vertices, so
the cone of a cell can be its vertices. This can be made more involved by
including edges and faces.

All the information for data layout is not in the DMComplex, but in the
PetscSection object. This is just
a map between pieces of the mesh, like vertices, and degrees of freedom,
which are offsets into a
PETSc Vec. All values are stored in Vecs. There is a convenience function
for creating this layout with
FEM information


http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/305aed156be4/src/snes/examples/tutorials/ex52.c#l188

but you can dot it yourself using the PetscSection functions to match any
LibMesh layout, and then call


http://petsc.cs.iit.edu/petsc/petsc-dev/annotate/305aed156be4/src/snes/examples/tutorials/ex52.c#l189

Let me know if this makes sense. Also, I have started the variable
coefficient stuff, but its not done yet.

     Matt


> Lastly,
> Are there any data structures to pass spatially varying element-wise
> material parameters to the inner loop of the assembly?
>
> for example, something like:
>
> diff -r 58bb1a4e8a0d src/snes/examples/tutorials/ex52_integrateElement.cu
> --- a/src/snes/examples/tutorials/ex52_integrateElement.cu      Tue Mar 27
> 23:22:11 2012 -0500
> +++ b/src/snes/examples/tutorials/ex52_integrateElement.cu      Mon Apr 23
> 09:36:30 2012 -0500
> @@ -3,8 +3,8 @@
>
>  #include "ex52_gpu.h"
>
> -__device__ vecType f1_laplacian(float u[], vecType gradU[], int comp) {
> -  return gradU[comp];
> +__device__ vecType f1_laplacian(float thermalconductivity, float u[],
> vecType gradU[], int comp) {
> +  return thermalconductivity*gradU[comp];
>  }
>
>
>
>
> Thanks,
> David
>
>
>
>
>
>
> On Mon, Apr 2, 2012 at 9:37 PM, Matthew Knepley <knepley at gmail.com> wrote:
>
>> On Wed, Mar 28, 2012 at 6:42 PM, Matthew Knepley <knepley at gmail.com>wrote:
>>
>>> On Wed, Mar 28, 2012 at 6:25 PM, David Fuentes <fuentesdt at gmail.com>wrote:
>>>
>>>> Yes. This would work.
>>>> I had trouble compiling in single precision using the some of the
>>>> external package options I was using for double.
>>>>
>>>
>>> Okay,  getting on it now.
>>>
>>
>> Okay, I have tested using PetscReal=double with floats on the GPU. If you
>> want doubles on the GPU, you can
>> currently change PETSc/FEM.py:434. I am deciding what the best way to
>> specify this type is.
>>
>>   Thanks,
>>
>>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120423/4676c467/attachment-0001.htm>