[MOAB-dev] Detecting file types

Jed Brown jed at 59A2.org
Mon Nov 30 15:47:07 CST 2009


On Mon, 30 Nov 2009 15:19:15 -0600, Steve Jackson <sjackson at cae.wisc.edu> wrote:

> Serious reason: DagMC has a feature that allows ray tracing to be
> performed directly on a CAD representation of a geometry, rather than
> on the faceted representation stored in MOAB.  This is done by calling
> CGM functions (specifically GeometryQueryTool::fire_ray).  This
> CGM-level ray casting only works when the relevant geometry is stored
> in CGM-- which is expected only if ReadCGM was used to import the
> geometry into MOAB.  In contrast, CAD-based ray casting should be
> disabled if the file was loaded by some other file loader.  So DagMC
> needs some way to find out if CGM was used to load data.

Does it need to know in advance, or can it just request the geometry
object when it needs it?  This would enable a user to set up the
mesh/geometry association any way they please, rather than necessarily
loading it in a particular way.

I know Tim is philosophically opposed to making either MOAB or CGM
depend on the other, but in that case, any code that necessarily depends
on both needs to be moved elsewhere.

> Cosmetic reason: DagMC passes some file loading options to
> MBInterface::load_file.  These options go unhandled by MOAB's native
> file reader, causing load_file to return the MB_UNHANDLED_OPTION error
> code.  This isn't really an error condition, though; we wouldn't pass
> the options in the first place if we knew the file was going to be
> handled by MOAB's native loader.

What are you going to do with this file if it's not loaded with the
geometry info you need?

There is a deeper issue here of finding out which options were actually
used.  Some options do not change the behavior of the object, they only
have memory/performance consequences, and may not be relevant for the
file type you are loading.  Other options completely produce completely
different semantics and the correctness of the program will rely on
these options being observed.  The current system is difficult to work
with because querying properties after the load uses a completely
different interface and isn't always possible.

Jed


More information about the moab-dev mailing list