itaps-parallel Questions about iMeshP

[Mark Shephard]

It would seam that there are interactions that have to be accounted for 
and the one mesh and it set of adjacencies will be real critical to 
getting that to work well in parallel.

Not clear to me it that really calls for "multiple partitions" of a 
single mesh instance at the iMeshP level. It obviously calls for 
properly controlling the parallel processing operations using 
information obtained from a mesh and its adjacency and (in the case of 
contact things) geometric proximity information.


Tim Tautges 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
>>>
>>>
>>>
>>
>>
>>
>