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 ([email protected]) (telecommuting from UW-Madison) phone: (608) 263-8485 1500 Engineering Dr. fax: (608) 263-4499 Madison, WI 53706