[MOAB-dev] Re: Some MOAB questions

[Jason Kraftcheck]

Tim Tautges wrote:
> [cc'ing moab-dev since some of these questions might be of general
> interest...]
> 
> 
> Milad Fatenejad wrote:
>> Hi Tim:
>> This is Milad. I had a few additional questions about MOAB that I was
>> hoping you could answer....
>>
>> 1) I noticed that in the SVN, trunk version there is code for a
>> StructuredElementSeq class which seems to provide some convenience
>> functions for dealing with structured meshes. Since I am dealing with
>> a 3D structured mesh this would be useful to me, but I noticed that
>> the header file doesn't get added to the include directory when you
>> install the code (StructuredElementSeq.hpp). Is this because the code
>> is still in development and shouldn't be used? Or is there some other
>> object I am supposed to use for manipulating structured grids...
>>
> 
> That's an oversight.  The structured mesh stuff should work; see
> scdseq_test.cpp for example usage.  The parallel stuff probably won't
> work with structured sequences, though.
> 

I'm not sure that this is an oversight.  Or rather, it is only an oversight
if accessing StructuredElementSeq objects and the SequenceManager directly
from applications is the intended API.  While we could go that route, I
think an API that is similar to the rest of the public API (e.g.
MBInterface) and that doesn't require access to MOAB's internals (e.g.
SequenceManager) might be a better solution.

>> 2) Is it possible to write out the MOAB hdf5 files in pieces? The way
>> I had written my code before enabled me to generate/write out my
>> meshes (which are very simple) in pieces so that I never had to store
>> the whole all the data in memory at one time. Is this possible with
>> MOAB?
> 
> I'll let Jason answer with more details, but you can pass individual
> sets to MOAB's write function to specify the sets you want to write.
> That would probably overwrite existing mesh in the same file, though. In
> general, since we try hard to minimize memory, writing the mesh usually
> isn't too much of an extra burden.
> 

MOAB doesn't support this.  We could possibly add support for this kind of
thing (by abstracting some of the existing code for parallel I/O that
already writes pieces of a mesh on different procs.)  But as Tim said, MOAB
has a reasonably compact mesh representation.  If you don't have any issues
with having the whole mesh in memory, there's no reason to pursue
work-arounds for a non-existent problem.

- jason