<div class="gmail_quote">On Tue, May 24, 2011 at 15:58, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org" target="_blank">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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:</div><div><br></div>iMesh(9) iBase_INVALID_ENTITY_COUNT: (<span>MOAB</span> Error Code: MB_TYPE_OUT_OF_RANGE)!</blockquote>
</div><br><div>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?</div>
<div><br></div><div>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.</div>