On 10-06-02 07:30 AM, Tim Tautges wrote:

On 06/01/2010 11:32 PM, Carl Ollivier-Gooch wrote:

...

In fact, as I read it, the spec says specifically that iMesh_addEntToSet gets used here, with a part handle passed as the set. This is no different, as I see it, from any other situation in which you're creating a partition rather than reading one. And yes, it's true that in the transition of setting up this (or any similar) partition, there's necessarily a limbo period in which entities haven't yet been assigned to parts. IMO, this is different than creating entities with no part assignment and leaving them in that state.

So this limbo period is allowed in your world? This is subtly different from the stricter requirement that there be no time when an entity is not in a Part. Mark S, are you sure you agree with this?

If this limbo period -isn't- allowed, I don't see any way to partition a mesh from serial. Am I missing something?

...

My issue with the whole "entities must belong to a part" thing is a consistency argument. I expect that, if we don't require all entities to be in parts, at least at the end of parallel services, some subsequent parallel operations will not be properly defined. I don't see that outcome as reasonable. Consider:

Premise 1 (written in the spec): An entity -must- have an owner if it's going to be modified. (Ownership == right to modify)

Premise 2: It's never safe for a service to assume that no other service will ever modify the mesh after it's done, nor that other services (whether or not they modify the mesh) can tolerate partless entities, even if they can be identified as such. (Ghosting patterns could change, for instance, making it so that entities that weren't ghosted now are, and need an owner for that reason.)

If those two premises hold up (and I obviously think they do), any parallel service that wants to work and play well with others needs to assign all entities to parts before completion.

Well, any services that modify mesh, anyway. There are one or two services working with mesh that don't modify it, you know. In making this interface work for the mesh modifying services, we shouldn't cripple those other ones too badly.

Flip side: we have to make sure those that modify mesh can function. Which gets us back to all entities needing to be in a part at service end.

Yes, I think this even

...

applies to the parallel meshing scenario we discussed in the telecon: the parallel version of this must, IMO, at the very least post-process the mesh that the parallel-unaware mesher produced to get stuff into parts. This would be a wrapper, not a mod to the mesher itself.

I do agree with most of the above points. But, that just imposes requirements on the state of the mesh after a parallel-aware service is done.

Fine, but that requirement should still be formalized and written into the spec.

...

As an aside, if an entity isn't explicitly assigned to a part, what should a function like getEntOwnerPart return? And does it pass the giggle test for this to -not- return the one part on a process when there is only one? And if unowned parts get an inferred value in this function, how does one do that in the presence of multiple parts per process and still avoid giggling?

That brings up an excellent point - what does getOwnerPartArr return for entities not owned by any Part *in a Partition*? Looks like we either need a stricter requirement, or we need a notion of some Part ID that's considered invalid. Otherwise, it's invalid to create a Partition and Parts and add entities to those parts in a subsequent operation.

I'm happy for getOwnerPart kinds of things to return an error when an unassigned entity is passed in. After all, the entity has no owner, so an error code like iMeshP_UNOWNED_ENTITY isn't unreasonable. Trickier for the array case, I admit... Carl -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Associate Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: [email protected] University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------