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
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?
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
-- You received this message because you are subscribed to the Google
Groups "sfepy-devel" group. To post to this group, send email to sfepy...@googlegroups.com. To unsubscribe from this group, send email to
sfepy-devel...@googlegroups.com. For more options, visit this group at
http://groups.google.com/group/sfepy-devel?hl=en.
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].
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
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
Hi Robert,
On Tue, Jun 8, 2010 at 6:17 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
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.
Ok, cool, it looks good. I like the use of assert and testing the entire set of group numbers. Actually, it turns out the numbering on the node groups is in fact positive (while element groups are negative), so I just switched the sign for the node group assertion.
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?
This is done, I sent you a pull request, or it's on the branch "med_mesh_test" on my github [1], along with the patch for positive node groups above.
The test file could be enhanced to test mesh writing too - another EasyToFix issue? :)
Sounds good, I'll see if I have more free time this weekend to work on it...some other things are demanding my attention now. :( Maybe someone else will beat me to it? ;) I'll add an issue to the issue tracker so we don't forget.
Greetings, Logan
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
On 06/09/10 03:54, Logan Sorenson wrote:
Hi Robert,
On Tue, Jun 8, 2010 at 6:17 AM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:
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.
Ok, cool, it looks good. I like the use of assert and testing the entire set of group numbers. Actually, it turns out the numbering on the node groups is in fact positive (while element groups are negative), so I just switched the sign for the node group assertion.
I have also removed the 'abs' line, as it is no-op.
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?
This is done, I sent you a pull request, or it's on the branch "med_mesh_test" on my github [1], along with the patch for positive node groups above.
Thanks, it's now at my github site.
The test file could be enhanced to test mesh writing too - another EasyToFix issue? :)
Sounds good, I'll see if I have more free time this weekend to work on it...some other things are demanding my attention now. :( Maybe someone else will beat me to it? ;) I'll add an issue to the issue tracker so we don't forget.
Thanks again!
r.
participants (2)
-
Logan Sorenson -
Robert Cimrman