On 06/07/10 16:57, Logan Sorenson wrote:
Hi Robert,
On Mon, Jun 7, 2010 at 6:50 AM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:
Hi Logan,
mat_id in Mesh is declared as int, so it can be, in principle, negative. However I am not sure, whether there are some silent implicit assumptions that on its sign in the code... Anyway, the reader can change the mat_id sign so that it is positive, no?
Ok, that was my thought as well, I assumed that the mat_id most likely should be positive. As far as I have seen, the MED numbers are all negative, so there should be no harm in running nm.abs over the mat_id array before passing it of to SfePy. But I wanted to make sure I'm not missing any silent assumptions... :)
I made a small patch for this and sent you a pull request on github or the code is available at [1].
It's in (github for the moment). I have also added verification of the negative id assumptions.
Could you put a small MED mesh to meshes/various_formats, and add it to tests/test_meshio.py, so that the reader is tested?
The test file could be enhanced to test mesh writing too - another EasyToFix issue? :)
Thanks! r.
Thanks! Logan
cheers, r.
Quoting Logan Sorenson<logan.s...@gmail.com>:
Hi all,
I was playing a bit with the grouping functionality in Salome which allows one to group similar elements and nodes into families. AFAIK, this more or less corresponds to the mat_id associated with the elements in SfePy. However, I couldn't find a way to explicitly specify the numbering, and the implicit numbering by Salome appears to write meshes with negative integers for the mat_id.
Are negative mat_ids allowed in SfePy? If not, I'll submit a patch for the MED format read code. Otherwise, we should correct the mat_ids in the comsol format write code, since negative domain numbers do not seem to be allowed there.
Thanks! Logan
[1] http://github.com/logansorenson/sfepy/tree/domain_numbering_fix