[Smtk-developers] SMTK mesh

[Robert Maynard]

As far as #1 goes I will also have to add a small layer between io and
smtk::mesh::moab to allow us to build without moab. I expect this will be
handled by a new abstract class ( maybe smtk::io::Reader/Writer? ) that
smtk::mesh::Interface manages.

On Tue, Mar 3, 2015 at 2:50 PM, David Thompson <david.thompson at kitware.com>
wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150303/b5c108cf/attachment.html>