IRel telecon notes

Wed, 2/16

Telecon times:

  • agreed on 12 CST on Thurs for meeting
  • every 2 wks, starting 2/24

What's relatable?

  • irel constructed assuming relatables were entities, sets; this is more from history than anything else
  • what are iField's relatable types?
  • Tensor field
  • collection of dofs? likely to need to relate collections of these (or their values, anyway) to mesh entities

3 types, from grep'ing for typedef in iField.h:

  • Domain
  • Tensor field
  • Distribution Function Kernel

Probably need to go back and add dofbucket or something like it, collection of dofs at a point

Next telecon: Thurs, 2/24, 12:00 CST

2/24 Notes

Who's on: Jim, Seegyoung, Tim, Fabien, Carl
  • iField requirements (any more that haven't been mentioned?)
  • summary of requirements from iGeom, iMesh
  • API strategy (how to handle growing list of relatable's, or, can we have both type safety and non-combinatorial explosion of # functions)
  • one-sided relations proposal (if there's time)
iField requirements:
  • constant-time retrieval needed for sure, maybe update too (and isn't it likely to be if retrieval is)
  • one-sided relations
iMesh, iGeom requirements:
  • from MOAB's point of view, don't want to prevent constant size per geometry entity storage
  • besides that, requirements are stated and summarized on wiki already
API strategy
  • problem: need to know what kind of things are related, so we know which functions to call in the underlying interfaces; however, knowing what types are there give us some type safety
  • varying the thing in a relation at the specific entity level would require too many tag queries
  • suggestion: keep entity type enumeration, but make access functions generic
  • Seegyoung: question of why we need to support "both"-type relations?
    . Tim: answer boils down to how do you refer from an entity on one side to multiple entities on the other side? Right now, the only way we refer to collections through iMesh/iGeom are as entity sets.
    . Carl: use of sets in relations is not MOAB-specific, since sets are part of iGeom/iMesh data model
    . Fabien: is there a grouping mechanism in FMDB?
    . Seegyoung: for relations, FMDB returns an iterator for the mesh entities related to a geometry entity
One-sided relations: support with a "NONE" type?
  • Carl: seems ok
  • Jim: ok from implementation point of view
  • Fabien: seems ok
  • Seegyoung: thinking about it
Jim: proposed keeping functionality of both-type, but change naming; think of this as a recursion type on the set, rather than changing the relation type on a side of the relation
  • consider next time

Next telecon: 3/10, 12:00 noon CST

3/10 Notes


  • Seegyoung's request for more detailed description of NONE proposal:
    #1. api list of get/set/removeRelation, and
    #2. input/output of each api, especially proposed alternative of iRel_getEntEntArrRelation.