[MOAB-dev] Q on initializing MOAB iMesh interface

Iulian Grindeanu iulian at mcs.anl.gov
Sat Jan 8 15:08:57 CST 2011


Hello,
Yes, I think this would be better. It should continue to allow multiple iMesh instances.

Also, iGeom implementation in MOAB should be changed in a similar way.

Currently only one iGeom instance is possible; a similar class is needed, that contains the 
global variables defined in iGeom_MOAB.cpp, and a pointer to Core (or MBiMesh?)

Thanks,
Iulian

----- Original Message -----
> Hi all,
> Currently in MOAB's iMesh implementation, the class structure looks
> like:
> 
> class MBiMesh : public Core
> {...}
> 
> It's done this way because the iMesh implementation needs to keep some
> member data that Core doesn't need. However, it
> also makes it impossible to construct an iMesh object from an existing
> Core object. I'd like to change that. What I'd
> like to do is change MBiMesh from "isA" to "hasA", i.e. to make
> MBiMesh point to an Interface object. The MBiMesh
> object would keep track of whether it constructed MOAB or was passed
> one, so it would know whether it could destroy it
> in iMesh_dtor. I'd also like to enable the Interface::query_interface
> method to return an iMesh instance, consistent
> with other interfaces it already handles. The net effect of all this
> would that applications could gain access to an
> iMesh interface on a transient basis, e.g. if they wanted to call a
> service implemented in iMesh but not MOAB.
> 
> Does anybody see any problem with this approach, or think I should do
> it differently?
> 
> - tim
> 
> --
> ================================================================
> "You will keep in perfect peace him whose mind is
> steadfast, because he trusts in you." Isaiah 26:3
> 
> Tim Tautges Argonne National Laboratory
> (tautges at mcs.anl.gov) (telecommuting from UW-Madison)
> phone: (608) 263-8485 1500 Engineering Dr.
> fax: (608) 263-4499 Madison, WI 53706


More information about the moab-dev mailing list