[Smtk-developers] SMTK mesh

[David Thompson]

Hi all,

As discussed, our options for smtk::mesh are

1. Finish abstracting MOAB out of Rob's smtk::mesh branch. Make mesh part of the SMTKCore library with MOAB as an optional, system/superbuild-provided library. This is the most preferable but would require a fair amount of work for dealing with element ranges efficiently. Testing with and without MOAB would be required.

2. Include MOAB in SMTK's third-party directory and either build it (with I/O dependencies like HDF5/NetCDF as optional, system/superbuild-provided) or allow an external MOAB to be given. On my system, building MOAB without any supporting I/O libraries takes about 12 seconds, which is not bad when compared to all of SMTK with Python wrapping on (about 170 seconds). The larger concern is that MOAB would add about 7 MiB of source code to the repo, while SMTK is currently at 33 MiB including git history; even if we remove MOAB from third-party later, it would be a big bump in the git history. Testing thoroughly would mean building with internal MOAB (no I/O), with internal MOAB (and external I/O libs) and with an external MOAB -- this would take more ongoing effort to test. However, this option requires less development effort up front.

3. Finally, we could make smtk::mesh its own optional library, dependent on SMTKCore. This is the least desirable solution because it leaves meshes as second-class citizens compared to attributes, models, and exporters -- but it requires the least work.

Any strong opinions? I prefer #1 if it is feasible in the time frame.

	David