Proposal for Requiring Save/Restore of Sets and Tags

[Carl Ollivier-Gooch]

On 09/29/2010 10:27 PM, Mark Miller wrote:
> Resending (orig. sent May 21, 2009) as per Seegyoung's inquiry regarding implementation's
> responsibilities of information to store persistently as well as recommendations on how
> Authors:
> -------
> Mark Miller<miller86 at llnl.gov>
> Jason Kraftcheck<kraftche at cae.wisc.edu>
>
>
> Proposal:
> ---------
>
> iMesh implementations shall be required to support saving and loading of set
> and tag data via the persistent storage methods, iMesh_save() and
> iMesh_load(), defined in the iMesh interface.  Implementations are free to
> choose how they meet this requirement.
>
> Rationale:
> ----------
>
> Sets and tags are part of the iMesh interface and data model.  An
> implementation of the iMesh API is a component that maintains the
> necessary data structures to implement that data model.  Given an API
> that is fundamentally an interface for interacting with this data
> structure and that provides functions to load and store it, an
> implementation of that API is incomplete if it cannot restore the
> complete data model that it is intended to maintain.
>
> Further, the inability to save and restore the entire data model is
> substantial practical barrier to interoperability and interchangeability
> of implementations.  Interoperability of persistently stored data between
> implementations is not achievable without imposing this requirement.
>
> Practical considerations:
> -------------------------
>
> While a common file format for all implementations may be impractical, the
> ability to store and subsequently retrieve a complete iMesh instance to/from
> persistent storage is a minimum requirement.  An implementation may
> maintain additional data beyond the iMesh data model for which a common
> file format may not be sufficient.  Further, the data model does not
> entirely constrain the data representation.  Implementations may implement
> the complete data model while using incompatible internal representations
> of the data (e.g. defining elements by vertices versus sub-elements of
> one less topological dimension.)
>
> In choosing a file format, there are several complicating factors to
> consider:
>    o Tags may be placed on entity sets as well as entities.
>    o Entity sets may contain entity sets as well as entities.
>    o The entity set containment graph may contain cycles.
>    o The entity set parent/child graph may contain cycles.

I don't think it's particularly relevant to the way these things are 
likely to be stored, but I strongly disagree, semantically, with 
allowing cycles.  Also, it's harder to implement these the infinite 
depth retrieval with cycles (not super hard, but harder).

Containment can be interpreted as subset or member.  Subsets clearly 
can't be cyclical (okay, you could have improper subsets in a cycle, but 
why?).  Membership also doesn't make sense:  set A contains B contains C 
contains A?  Draw me that Venn diagram!

Parent-child semantics also don't make sense cyclically: A is the parent 
of B is the parent of C is the parent of A?

Finally, can anyone describe an actual use case for cycles?

>    o Preserving valid references in tag data of type iBase_ENTITY_HANDLE.
>    o Scalability for large numbers of entity sets (>  10^6).
>    o Time/Storage performance issues associated with these factors.
>    o Opportunities for cross-exploitation of existing formats/tools.
>    o Partial load/store.
> A key issue is that storage of iMesh data requires BOTH the ability to store
> meshes and mesh-related data as well as potentially very large graphs
> representing the entity sets, their tags and their relationships.

Other that the set semantics implied here, I have no objections.

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
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/
------------------------------------------------------------------------