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

[Jed Brown]

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20110609/a6df9801/attachment.htm>