itaps-parallel Questions about iMeshP

[Devine, Karen D]

Hi, Tim.

I'm not sure what you mean by "partices with vertices."  But I'll describe
what I've seen with PIC codes.

All the PIC codes I've seen up-close use a static graph-based partition of
the mesh for the finite-element computation.  Then they use a geometric
partition for the particle calculation.  Some partition the particles
directly (i.e., give geometric coordinates for the particles).  Others
weight mesh elements by the number of particles they contain and then apply
the geometric partitioner to the weighted mesh.  They use a geometric
partitioner because (1) they partition the particles frequently and need a
fast partitioner, and (2) the geometric locality of particles is important
in the particle calculations.

The same two reasons apply to the contact problem; replace "particles" with
"surfaces."

Karen


On 12/21/09 9:56 AM, "Tim Tautges" <tautges at mcs.anl.gov> wrote:

> Interesting.  I've thought about PIC codes in the context, but always wondered
> whether apps would consider it overkill
> to do the particles with vertices (which I think is what you're implying
> below?  Or not?)
> 
> - tim
> 
> Devine, Karen D wrote:
>> Thanks, Tim, for providing a good example.  Here's another:  a
>> particle-in-cell code can partition the mesh one way for force calculations
>> and a different way for particle calculations.  The force calculations use a
>> static partitioning; the particle calculations use a dynamic partitioning
>> that attempts to maintain particle balance.
>> 
>> Karen
>> 
>> 
>> 
>> 
>> 
>> On 12/18/09 9:54 AM, "Tim Tautges" <tautges at mcs.anl.gov> wrote:
>> 
>>> The best example, brought up by both Karen and me IIRC, is of
>>> large-deformation transient dynamics with contact, where
>>> the FE solution of the dynamics is solved on 3d elements on one partition,
>>> and
>>> the contact solution is solved on faces
>>> on a different partition.  Many believe it was this capability that made
>>> truly
>>> scalable parallel FEM with contact even
>>> possible.  See e.g.
>>> 
>>> Transient dynamics simulations: parallel algorithms for contact detection
>>> and
>>> smoothed particle hydrodynamics,
>>> Proceedings of the 1996 ACM/IEEE conference on Supercomputing, 1996.
>>> 
>>> That's just one reference, there are many others for that particular work.
>>> 
>>> I think the details of multiple *active* partitions still need some work,
>>> both
>>> in use cases and in how they behave under
>>> iMeshP.  Normally I wouldn't advocate such an unexplored thing being part of
>>> the initial interface definition, but in
>>> this case I think it's an important enough capability that it's justified.
>>> 
>>> - tim
>>> 
>>> Mark Beall wrote:
>>>> As a more general context to the questions that Saurabh asked, the main
>>>> questions we have about iMeshP are issues related to having multiple
>>>> partitions. Although we won't be supporting that for now (since our
>>>> software doesn't support that), it would be helpful in understanding
>>>> that need if someone could give some examples of how this functionality
>>>> would be used.
>>>> 
>>>> mark
>>>> 
>>>> 
>>> --
>>> ================================================================
>>> "You will keep in perfect peace him whose mind is
>>>    steadfast, because he trusts in you."               Isaiah 26:3
>>> 
>>>               Tim Tautges            Argonne National Laboratory
>>>           (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>>>           phone: (608) 263-8485      1500 Engineering Dr.
>>>             fax: (608) 263-4499      Madison, WI 53706
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> --
> ================================================================
> "You will keep in perfect peace him whose mind is
>    steadfast, because he trusts in you."               Isaiah 26:3
> 
>               Tim Tautges            Argonne National Laboratory
>           (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>           phone: (608) 263-8485      1500 Engineering Dr.
>             fax: (608) 263-4499      Madison, WI 53706
> 
> 
>