[MOAB-dev] iMesh_setAdjTable() causes error in iMesh_load()

[Iulian Grindeanu]

----- Original Message -----
> On Tue, May 24, 2011 at 15:58, Jed Brown < jed at 59a2.org > wrote:
> 
> 
> 
> I set the adjacency table to iBase_AVAILABLE for the diagonal entries,
> then load a file (e.g. he6.h5m from Iulian). This worked a couple
> weeks ago, but now I get an error:
> 
> iMesh(9) iBase_INVALID_ENTITY_COUNT: ( MOAB Error Code:
> MB_TYPE_OUT_OF_RANGE)!
> 
> This still isn't fixed, so I've been using r4789 which I thought was
> functional. Unfortunately, I still can't write out the "real" mesh
> files because iMesh_save() fails with iBase_NOT_SUPPORTED. I know I
> used this a few weeks ago, but I don't know if it was before or after
> I updated and then retreated part way to r4789. It's possible that my
> code is putting something different into the mesh now, but I don't
> think so. Is there a way I can get more information, like *why*
> iMesh_save() is not supported in this case, but works fine for simple
> files?
> 

he6.h5m is a file that should contain only hexas and the skin organized in 3 neumann sets (bottom, top and lateral quads)
Are you loading it with iMesh, and then saving it again?

Can you do an 
mbconvert he6.h5m newhe6.h5m ?

The new one will be stripped down to bare essentials (the sets should be preserved)

Maybe it is something wrong in he6.h5m, although I can't say what.

Iulian

> 
> As a related matter, I would very much like to have a way to find the
> line where the error was generated, perhaps by setting my own error
> handler. If this sort of error occurs in PETSc (or good Python code,
> etc), the error message presents me with a stack trace and the reason
> why the error condition was raised. That way I can be looking at the
> logic responsible in seconds (PETSc even has options to attach a
> debugger on error or to open the source file and line number in a
> running Emacs session). Sometimes it is still work to find out why the
> condition was not satisfied (e.g. incompatible data put in a long time
> earlier and not validated at that time), but the location at which the
> error condition was raised is essential information.