itaps-parallel Comments on parallel stuff so far.

[Tim Tautges]

Some questions of Carl's and my comments on his that I missed in my last 
message:

> On the question of how to add entities to parts, I think we need to 
> examine the use cases for adding entities to parts.  I can think of 
> several scenarios:
> 
>   1.  A new entity has been created by a modify operation and needs to 
> be associated with a part.
>   2.  An entity is being migrated from one part to another (small 
> one-to-one migration due to change of ownership; data is almost 
> certainly moving from one part to another).
>   3.  A copy is being created (depending on the implementation, some 
> data may have to copied from one part to another).
>   4.  A new partition has been created and parts must be populated 
> (massive all-to-all migration; vast amounts of data flying everywhere).
> 
> That list probably isn't exhaustive, but it'll do for now.  Of those 

I think you missed the most common use case: assign entity to part, e.g. 
as called from a partitioning tool.  Note this is different from 
migrate.  As I have mentioned before, I think we shouldn't always assume 
part assignment and migration go together (though they're not always 
separate either, e.g. 2 above).


> Tim's stuff:
> 
> getEntByTypeAndTagPar, getEntSetByTagPar: We don't have this
> functionality in serial.  Maybe we should, but we currently don't.
> 

Yes, this is not in the serial interface.  I feel like it should be, but 
I'm loath to suggest extensions right about now.  It'll definitely be 
part of any good data sorting and searching interface/tool.

> getTag*Operate: Again, we haven't got this in serial.

Correct.  I feel like this would be valuable to have in parallel (and 
have at least one example of another code using it to great affect).

   Does the
> existence of such operations imply that we expect to implement fields as 
> tags? (Because that wasn't what I was assuming about field 
> implementations at all, personally...)  Note that I'm not opposed to 
> this sort of global reduction operation, I just wonder whether it'll see 
> use outside of field-like situations.  If not, then it should be in 
> parallel fields, not parallel mesh, and usage for 
> fields-implemented-as-tags should be handled there.

1. Any field interface that's not able to operate on tag data on a mesh 
will be dead on arrival, at least with me.  There's simply too much to 
gain using data from the mesh directly not to do this.  I don't mean to 
imply that *all* the data will be tags on a mesh (I strongly feel the 
opposite is true, in fact).

2. It may be that a field interface is a better place to address the 
global reduce type operations, though IMO it's pretty close to being 
useful enough to go into parallel iMesh.

> 
> Global IDs:
> 
> One question here.  As I understand it, the intention that 
> getEntHandle[Arr] will return a local handle (owned, copied, or ghosted) 
> for the global ID if possible, and otherwise give an error.  Is that 
> correct?

Yes.

- tim

> 
> I now return you to your regularly scheduled afternoon.
> 
> Carl
> 
> 

-- 
================================================================
"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