IRel telecon notes¶
- agreed on 12 CST on Thurs for meeting
- every 2 wks, starting 2/24
- 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:
- 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)
- constant-time retrieval needed for sure, maybe update too (and isn't it likely to be if retrieval is)
- one-sided relations
- 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
- 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
- Carl: seems ok
- Jim: ok from implementation point of view
- Fabien: seems ok
- Seegyoung: thinking about it
- consider next time
Next telecon: 3/10, 12:00 noon CST
- 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.