itaps-parallel Proposal for handling queries with parts, sets,and partitions

[Mark Shephard]

Mark,

The short answer to your question on defining iMesh functions to map 
between the two forms have been included in iMesh. I agree that having 
something for that would be useful. To the best of my knowledge, most 
applications tend to rely on having one or the other as their base form. 
Thus interoperability of applications could benefit from the ability to 
go between the two. In addition, there may be times where one is fully 
one way and wants some specific aspects in the other. As an example, in 
the case of a classification based approach, it could be some specific 
reverse classification information that is desired for a few specific 
things one may want to define and store the reverse classification sets 
for (e.g., the mesh faces on a model face that has a natural boundary 
condition.)

Note that in the particular formalism of classification and reverse 
classification the RPI group uses, each mesh entity maintains 
classification against the single lowest order model entity it is on, 
and reverse classification is specifically the set of equal order mesh 
entities classified on a model entity (adjacency information can quickly 
tell you any other information).

Since iMesh does not have a stated formalism of classification and 
reverse classification, I do not know how easy it would be to really add 
the types of functions you mention to iMesh. Obviously the RPI group 
would be supportive of supporting such things. However, I expect there 
would be some objections to doing that.

Mark

Mark Miller wrote:
> On the classification, reverse-classification issue, has anyone considered the utility of adding
> functions to iMesh like the following.
> 
> The functions below basically implement the 'dual' nature of the classification, reverse-classification
> representation of key database content. In Silo, we do something similar with materials. Some
> applications define materials by defining a material 'value' for every 'zone' in the mesh (classification) and
> some do it by defining for each material, the zones that are contained in that material (reverse classification).
> We have a function in Silo that simply maps from one to the other as the needs of the application(s) using
> material information vary. I am wondering if we can basically add something similar to iMesh.
> Below is an albeit not very well thought out suggestion. If there is interest, its a starting point...
> 
> 
> The following function will create the a 'collection of sets' dual to a given
> entity-level tag defined over an array of entities. Calling this function has the effect of creating in the
> iMesh instance a collection of sets such that each set contains
> entities given in 'entity_handles' with a common tag value. The sets could be returned
> in the call (which I've chosen not to do here). Or, they could be queried back
> out from the root. In addition, some 'filtering' could be added to create sets
> for only some tag values, or to specify ranges of tag values (for non-discrete
> tags).
> 
>   void iMesh_createDualSetsFromTagValues(iMesh_Instance instance,
> 
>                            /*in*/ const iBase_EntityHandle* entity_handles,
> 
>                            /*in*/ const int entity_handles_size,
> 
>                            /*in*/ const iBase_TagHandle tag_handle,
> 
>                             /*out*/ int *err);
> 
> The following function does the 'opposite' of the above. That is, it creates an entity-level
> tag over the set of entities represented by the union of all the entities in sets specified
> by the 'set_handles' array. It will create a different tag value for each set and then
> assign that value to all entities in the given set. You could imagine passing to iMesh
> the set of 'values' it should assign as well.
> 
>   void iMesh_createDualTagValuesFromSets(iMesh_Instance instance,
> 
>                            /*in*/ const iBase_EntitySetHandle* set_handles,
> 
>                            /*in*/ const int set_handles_size,
> 
>                            /*in*/ const iBase_TagHandle tag_handle,
> 
>                             /*out*/ int *err);
> 
> Mark
> 
> Mark Shephard wrote:
> 
>> Since the first thing that was agreed to is that there would be the
>> ability to deal parts that does not require an implementation to do
>> things via sets (reverse classification), I sure hope we are not getting
>> this issue confused again. As discussed in some technical detail at the
>> boot camp, there are two high level approaches one based on
>> classification (no use of sets) and reverse classification (what sets do
>> well). All the SCOREC tools that are being used for parallel adaptive
>> simulations, and (in the past) for parallel mesh generation, are based
>> on a classification approach.
>>
>> Onkar Sahni wrote:
>>>> So again, I go back to asking: what are the core needs that prevent us
>>>> from using sets as both parts and partitions?  The entity set mechanism
>>>> was designed with this specific usage in mind.
>>> If "sets as both parts and partitions" mean using entity-sets then we have
>>> already discussed this in great detail. I think the question in discussion
>>> is irrespective of how one implements parts and partitions? If I
>>> understood the question right then we need to answer queries which involve
>>> a specific part and a specific entity-set (where entity-set may span more
>>> than one part, may be local to a process). Now, if it is implied that
>>> choosing entity-sets for both parts and partitions allows to use set
>>> operations (booleans), outside the interface explicitly by applications,
>>> to answer such queries well then applications might as well do it in other
>>> equivalent ways (for example, loop over entities in set and ask residence
>>> parts to get entities in the entity-sey belonging to a specific part).
>>>
>>> - Onkar
>>>
> 
> --
> Mark C. Miller, Lawrence Livermore National Laboratory
> email: mailto:miller86 at llnl.gov
> (M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
> (Th/F)  (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
> 
>