itaps-parallel One particularly difficult thing in one of the use cases...

[Carl Ollivier-Gooch]

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: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------