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

[Mark Miller]

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!!)