[MOAB-dev] Using Mesquite with MOAB

[Jason Kraftcheck]

Tim Tautges wrote:
> 
> 
> Jason Kraftcheck wrote:
>> Roman Putanowicz wrote:
> 
>>
>> Those are mostly the default options.  I think it would be the same to
>> do:
>>   --prefix=/usr/local/install --enable-shared
>>
>>> and Mesquite-2.99 with options:
>>>  --prefix=/usr/local/install/' '--enable-imesh'"
>>>
>>> Then I am lost. I do not see the way to transer MBInterface* pointer
>>> to iMesh_Instance.
>>>
>>> If I do just bold cast like (which I know fill fail on runtime :)
>>>
>>> MBCore mesh;
>>> ....
>>> iMesh_Instance mp = (iMesh_Instance)&mesh;
>>>
>>
>> This definitely will not work.  There is no method to convert between an
>> MBInterface* and an iMesh_Instance because, for conformance with the
>> iMesh
>> API specification, our implementation of the iMesh interface must impose
>> additional constraints on the state of the MOAB data model that could be
>> undercut by accessing the underlying MBInterface instance directly. 
>> The two
>> options at present are to either a) always work through the iMesh API
>> rather
>> than MBInterface or b) provide an implementation of the Mesquite::Mesh
>> interface that communicates with MOAB through the MBInterface API rather
>> than the iMesh one.  The latter is something that I have been considering
>> including in Mesquite for some time, but have never had time to do.
>>
>>
> 
> I think we really need to be able to fire up an iMesh instance from an
> existing MBInterface*, for cases where the iMesh API is more convenient;
> I just ran across such a case last week, where I needed connectivities
> as an array with offsets.  In what way does iMesh constrain the MOAB
> data model, or is it more of an implementation issue that we could correct?
> 

The first example that comes to mind is the handling of the creation of
lower-dimension entities (all the stuff with setAdjTable).


> Having to construct a MOAB-specific API for Mesquite just because the
> application isn't completely iMesh-based blows a big part of our
> interoperability argument in ITAPS.
> 

Then we need to move the setAdjTable functionality (and any other such
things) into MOAB core.

- jason