Hi all,
I added to the existing Comsol meshio faciliites to implement full read/write for SfePy suported types. Hope someone can find it useful. At the very least, it should make comparisons between Comsol and SfePy easier. The code is on the comsol_mesh branch at [1].
Regards, Logan
[1] http://github.com/logansorenson/sfepy/tree/comsol_mesh
-- 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 Logan,
On 05/22/10 18:59, Logan Sorenson wrote:
Hi all,
I added to the existing Comsol meshio faciliites to implement full read/write for SfePy suported types. Hope someone can find it useful. At the very least, it should make comparisons between Comsol and SfePy easier. The code is on the comsol_mesh branch at [1].
I have tried several meshes with different kinds of elements, e.g.
./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt ./postproc.py cyli.txt
and it worked perfectly!
Thanks! r.
Regards, 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.
Hey Robert,
On Mon, May 24, 2010 at 4:34 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
Hi Logan,
On 05/22/10 18:59, Logan Sorenson wrote:
Hi all,
I added to the existing Comsol meshio faciliites to implement full read/write for SfePy suported types. Hope someone can find it useful. At the very least, it should make comparisons between Comsol and SfePy easier. The code is on the comsol_mesh branch at [1].
I have tried several meshes with different kinds of elements, e.g.
./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt ./postproc.py cyli.txt
and it worked perfectly!
I tried to run the mesh generated by Salome and converted using convert_mesh.py to Comsol format. It looks like Comsol can read the mesh okay, but when I run the Comsol solution it gives some errors about inverted elements and the solution looks strange compared to a mesh generated directly in Comsol. Therefore, I think that something is not quite right in the implementation of the Comsol write code. I know from reading and writing a Comsol generated mesh file that some of the elements get reordered by SfePy, so maybe this is causing the error. I will look more into it, but just wanted to post a warning if anyone is planning to use this to create Comsol meshes.
Thanks! r.
No problem! Logan
Regards, Logan
On 05/25/10 23:33, Logan Sorenson wrote:
Hey Robert,
On Mon, May 24, 2010 at 4:34 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi Logan,
On 05/22/10 18:59, Logan Sorenson wrote:
Hi all,
I added to the existing Comsol meshio faciliites to implement full read/write for SfePy suported types. Hope someone can find it useful. At the very least, it should make comparisons between Comsol and SfePy easier. The code is on the comsol_mesh branch at [1].
I have tried several meshes with different kinds of elements, e.g.
./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt ./postproc.py cyli.txt
and it worked perfectly!
I tried to run the mesh generated by Salome and converted using convert_mesh.py to Comsol format. It looks like Comsol can read the mesh okay, but when I run the Comsol solution it gives some errors about inverted elements and the solution looks strange compared to a mesh generated directly in Comsol. Therefore, I think that something is not quite right in the implementation of the Comsol write code. I know from reading and writing a Comsol generated mesh file that some of the elements get reordered by SfePy, so maybe this is causing the error. I will look more into it, but just wanted to post a warning if anyone is planning to use this to create Comsol meshes.
FYI: The orientation of elements (= ordering of vertices in connectivity) is depicted in [2].
cheers, r.
[1] http://github.com/logansorenson/sfepy/tree/comsol_mesh [2] http://docs.sfepy.org/doc-devel/users_guide.html#fields
On Wed, May 26, 2010 at 6:52 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 05/25/10 23:33, Logan Sorenson wrote:
Hey Robert,
On Mon, May 24, 2010 at 4:34 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi Logan,
On 05/22/10 18:59, Logan Sorenson wrote:
Hi all,
I added to the existing Comsol meshio faciliites to implement full read/write for SfePy suported types. Hope someone can find it useful. At the very least, it should make comparisons between Comsol and SfePy easier. The code is on the comsol_mesh branch at [1].
I have tried several meshes with different kinds of elements, e.g.
./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt ./postproc.py cyli.txt
and it worked perfectly!
I tried to run the mesh generated by Salome and converted using convert_mesh.py to Comsol format. It looks like Comsol can read the mesh okay, but when I run the Comsol solution it gives some errors about inverted elements and the solution looks strange compared to a mesh generated directly in Comsol. Therefore, I think that something is not quite right in the implementation of the Comsol write code. I know from reading and writing a Comsol generated mesh file that some of the elements get reordered by SfePy, so maybe this is causing the error. I will look more into it, but just wanted to post a warning if anyone is planning to use this to create Comsol meshes.
FYI: The orientation of elements (= ordering of vertices in connectivity) is depicted in [2].
Ah, yes, I used these to figure out the difference in node ordering b/w Comsol and SfePy. It looks like the 2_4 and 3_8 elements have different nodal ordering.
What I should have said is that when I read the mesh into SfePy, the rows of the conn array are interchanged. Then when I write back out the same mesh, the rows of elements will obviously be different since I'm just following the order of the conn array. I guess there is an internal sorting algorithm in SfePy for the conn array? I still don't understand why this would lead to problems in Comsol though...
Here's an example to clarify the problem:
./script/convert_mesh.py meshes/various_formats/comsol_tri.txt comsol_tri2.txt diff meshes/various_formats/comsol_tri.txt comsol_tri2.txt
Ideally, I suppose the two meshes should match exactly. I'll try some more simple examples to see what the problem is in Comsol.
Thanks for the help! Logan
cheers, r.
On 05/26/10 16:39, Logan Sorenson wrote:
On Wed, May 26, 2010 at 6:52 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 05/25/10 23:33, Logan Sorenson wrote:
Hey Robert,
On Mon, May 24, 2010 at 4:34 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi Logan,
On 05/22/10 18:59, Logan Sorenson wrote:
Hi all,
I added to the existing Comsol meshio faciliites to implement full read/write for SfePy suported types. Hope someone can find it useful. At the very least, it should make comparisons between Comsol and SfePy easier. The code is on the comsol_mesh branch at [1].
I have tried several meshes with different kinds of elements, e.g.
./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt ./postproc.py cyli.txt
and it worked perfectly!
I tried to run the mesh generated by Salome and converted using convert_mesh.py to Comsol format. It looks like Comsol can read the mesh okay, but when I run the Comsol solution it gives some errors about inverted elements and the solution looks strange compared to a mesh generated directly in Comsol. Therefore, I think that something is not quite right in the implementation of the Comsol write code. I know from reading and writing a Comsol generated mesh file that some of the elements get reordered by SfePy, so maybe this is causing the error. I will look more into it, but just wanted to post a warning if anyone is planning to use this to create Comsol meshes.
FYI: The orientation of elements (= ordering of vertices in connectivity) is depicted in [2].
Ah, yes, I used these to figure out the difference in node ordering b/w Comsol and SfePy. It looks like the 2_4 and 3_8 elements have different nodal ordering.
What I should have said is that when I read the mesh into SfePy, the rows of the conn array are interchanged. Then when I write back out the same mesh, the rows of elements will obviously be different since I'm just following the order of the conn array. I guess there is an internal sorting algorithm in SfePy for the conn array? I still don't understand why this would lead to problems in Comsol though...
I was thinking more about that nodal ordering (when wrong, it causes negative volume elements and other weird errors).
Here's an example to clarify the problem:
./script/convert_mesh.py meshes/various_formats/comsol_tri.txt comsol_tri2.txt diff meshes/various_formats/comsol_tri.txt comsol_tri2.txt
I can see only whitespace differences in the order of elements (trinagles). Do you see something different?
Ideally, I suppose the two meshes should match exactly. I'll try some more simple examples to see what the problem is in Comsol.
OK, but remember that sfepy does not use lower level entities in the mesh like edges, faces etc.
cheers, r.
Hi Robert,
On Wed, May 26, 2010 at 11:24 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 05/26/10 16:39, Logan Sorenson wrote:
On Wed, May 26, 2010 at 6:52 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 05/25/10 23:33, Logan Sorenson wrote:
Hey Robert,
On Mon, May 24, 2010 at 4:34 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi Logan,
On 05/22/10 18:59, Logan Sorenson wrote:
Hi all,
I added to the existing Comsol meshio faciliites to implement full read/write for SfePy suported types. Hope someone can find it useful. At the very least, it should make comparisons between Comsol and SfePy easier. The code is on the comsol_mesh branch at [1].
I have tried several meshes with different kinds of elements, e.g.
./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt ./postproc.py cyli.txt
and it worked perfectly!
I tried to run the mesh generated by Salome and converted using convert_mesh.py to Comsol format. It looks like Comsol can read the mesh okay, but when I run the Comsol solution it gives some errors about inverted elements and the solution looks strange compared to a mesh generated directly in Comsol. Therefore, I think that something is not quite right in the implementation of the Comsol write code. I know from reading and writing a Comsol generated mesh file that some of the elements get reordered by SfePy, so maybe this is causing the error. I will look more into it, but just wanted to post a warning if anyone is planning to use this to create Comsol meshes.
FYI: The orientation of elements (= ordering of vertices in connectivity) is depicted in [2].
Ah, yes, I used these to figure out the difference in node ordering b/w Comsol and SfePy. It looks like the 2_4 and 3_8 elements have different nodal ordering.
What I should have said is that when I read the mesh into SfePy, the rows of the conn array are interchanged. Then when I write back out the same mesh, the rows of elements will obviously be different since I'm just following the order of the conn array. I guess there is an internal sorting algorithm in SfePy for the conn array? I still don't understand why this would lead to problems in Comsol though...
I was thinking more about that nodal ordering (when wrong, it causes negative volume elements and other weird errors).
True, I think you are very right to consider nodal ordering. I checked the SfePy node ordering at [2] against the node ordering described in the Comsol documentation, so that's how I arrived at the values in the code. I think it's okay, but perhaps I made an error. Do you have access to the Comsol documentation? If not, maybe I can send you the relevant section offline. :)
Here's an example to clarify the problem:
./script/convert_mesh.py meshes/various_formats/comsol_tri.txt comsol_tri2.txt diff meshes/various_formats/comsol_tri.txt comsol_tri2.txt
I can see only whitespace differences in the order of elements (trinagles). Do you see something different?
Ooops, you are right. I didn't check the result of the diff command carefully in this case. I'll send a Comsol generated mesh which shows the difference. I think it may only be obvious for the 2_4 and 3_8 elements, since SfePy and Comsol share the node ordering for 2_3 and 3_4 elements.
Ideally, I suppose the two meshes should match exactly. I'll try some more simple examples to see what the problem is in Comsol.
OK, but remember that sfepy does not use lower level entities in the mesh like edges, faces etc.
Ok, this could be another source of error. I belive in the comsol read code (which was based off the existing code for 2_3 elements :) ), it should only read the elements of the dimension of the mesh. Also, the write code should just write the SfePy conn arrays, so the lower level entities would be stripped as you say. I'm not sure if Comsol needs these lower level entities, or if it's smart enough to regenerate them from the higher level. I guess I need to do more testing :)
Thanks for all the comments! :)
Best regards, Logan
[1] http://github.com/logansorenson/sfepy/tree/comsol_mesh [2] http://docs.sfepy.org/doc-devel/users_guide.html#fields
Hi Robert,
Ok, I figured out the problem, and in fact it had nothing to do with the mesh at all. Instead, some boundary conditions had been set in Comsol which were giving me unexpected results. Upon fixing the boundary conditions, I obtained the results I expected.
So it looks like Comsol meshing is good to go in SfePy! :) Sorry for the noise.
On Wed, May 26, 2010 at 12:12 PM, Logan Sorenson logan.s...@gmail.com wrote:
Hi Robert,
On Wed, May 26, 2010 at 11:24 AM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 05/26/10 16:39, Logan Sorenson wrote:
On Wed, May 26, 2010 at 6:52 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 05/25/10 23:33, Logan Sorenson wrote:
Hey Robert,
On Mon, May 24, 2010 at 4:34 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
Hi Logan,
On 05/22/10 18:59, Logan Sorenson wrote: > > Hi all, > > I added to the existing Comsol meshio faciliites to implement full > read/write for SfePy suported types. Hope someone can find it useful. > At the very least, it should make comparisons between Comsol and SfePy > easier. The code is on the comsol_mesh branch at [1].
I have tried several meshes with different kinds of elements, e.g.
./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt ./postproc.py cyli.txt
and it worked perfectly!
I tried to run the mesh generated by Salome and converted using convert_mesh.py to Comsol format. It looks like Comsol can read the mesh okay, but when I run the Comsol solution it gives some errors about inverted elements and the solution looks strange compared to a mesh generated directly in Comsol. Therefore, I think that something is not quite right in the implementation of the Comsol write code. I know from reading and writing a Comsol generated mesh file that some of the elements get reordered by SfePy, so maybe this is causing the error. I will look more into it, but just wanted to post a warning if anyone is planning to use this to create Comsol meshes.
FYI: The orientation of elements (= ordering of vertices in connectivity) is depicted in [2].
Ah, yes, I used these to figure out the difference in node ordering b/w Comsol and SfePy. It looks like the 2_4 and 3_8 elements have different nodal ordering.
What I should have said is that when I read the mesh into SfePy, the rows of the conn array are interchanged. Then when I write back out the same mesh, the rows of elements will obviously be different since I'm just following the order of the conn array. I guess there is an internal sorting algorithm in SfePy for the conn array? I still don't understand why this would lead to problems in Comsol though...
I was thinking more about that nodal ordering (when wrong, it causes negative volume elements and other weird errors).
True, I think you are very right to consider nodal ordering. I checked the SfePy node ordering at [2] against the node ordering described in the Comsol documentation, so that's how I arrived at the values in the code. I think it's okay, but perhaps I made an error. Do you have access to the Comsol documentation? If not, maybe I can send you the relevant section offline. :)
Here's an example to clarify the problem:
./script/convert_mesh.py meshes/various_formats/comsol_tri.txt comsol_tri2.txt diff meshes/various_formats/comsol_tri.txt comsol_tri2.txt
I can see only whitespace differences in the order of elements (trinagles). Do you see something different?
Ooops, you are right. I didn't check the result of the diff command carefully in this case. I'll send a Comsol generated mesh which shows the difference. I think it may only be obvious for the 2_4 and 3_8 elements, since SfePy and Comsol share the node ordering for 2_3 and 3_4 elements.
After fixing my boundary conditions, it worked for 3_8 elements, so I think the node ordering is correct.
Ideally, I suppose the two meshes should match exactly. I'll try some more simple examples to see what the problem is in Comsol.
OK, but remember that sfepy does not use lower level entities in the mesh like edges, faces etc.
Ok, this could be another source of error. I belive in the comsol read code (which was based off the existing code for 2_3 elements :) ), it should only read the elements of the dimension of the mesh. Also, the write code should just write the SfePy conn arrays, so the lower level entities would be stripped as you say. I'm not sure if Comsol needs these lower level entities, or if it's smart enough to regenerate them from the higher level. I guess I need to do more testing :)
It looks like it isn't a problem for the lower level entities to be missing from the Comsol mesh.
Thanks again! Logan
> [1] http://github.com/logansorenson/sfepy/tree/comsol_mesh [2] http://docs.sfepy.org/doc-devel/users_guide.html#fields
On 05/26/10 20:18, Logan Sorenson wrote:
Hi Robert,
Ok, I figured out the problem, and in fact it had nothing to do with the mesh at all. Instead, some boundary conditions had been set in Comsol which were giving me unexpected results. Upon fixing the boundary conditions, I obtained the results I expected.
Great!
So it looks like Comsol meshing is good to go in SfePy! :) Sorry for the noise.
No problem. I guess we have another topic to document :)
thanks! r.
On Wed, May 26, 2010 at 12:12 PM, Logan Sorenson logan.s...@gmail.com wrote:
Hi Robert,
On Wed, May 26, 2010 at 11:24 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 05/26/10 16:39, Logan Sorenson wrote:
On Wed, May 26, 2010 at 6:52 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote:
On 05/25/10 23:33, Logan Sorenson wrote:
Hey Robert,
On Mon, May 24, 2010 at 4:34 AM, Robert Cimrmancimr...@ntc.zcu.cz wrote: > > Hi Logan, > > On 05/22/10 18:59, Logan Sorenson wrote: >> >> Hi all, >> >> I added to the existing Comsol meshio faciliites to implement full >> read/write for SfePy suported types. Hope someone can find it useful. >> At the very least, it should make comparisons between Comsol and SfePy >> easier. The code is on the comsol_mesh branch at [1]. > > I have tried several meshes with different kinds of elements, e.g. > > ./script/convert_mesh.py meshes/3d/cylinder.mesh cyli.txt > ./postproc.py cyli.txt > > and it worked perfectly! >
I tried to run the mesh generated by Salome and converted using convert_mesh.py to Comsol format. It looks like Comsol can read the mesh okay, but when I run the Comsol solution it gives some errors about inverted elements and the solution looks strange compared to a mesh generated directly in Comsol. Therefore, I think that something is not quite right in the implementation of the Comsol write code. I know from reading and writing a Comsol generated mesh file that some of the elements get reordered by SfePy, so maybe this is causing the error. I will look more into it, but just wanted to post a warning if anyone is planning to use this to create Comsol meshes.
FYI: The orientation of elements (= ordering of vertices in connectivity) is depicted in [2].
Ah, yes, I used these to figure out the difference in node ordering b/w Comsol and SfePy. It looks like the 2_4 and 3_8 elements have different nodal ordering.
What I should have said is that when I read the mesh into SfePy, the rows of the conn array are interchanged. Then when I write back out the same mesh, the rows of elements will obviously be different since I'm just following the order of the conn array. I guess there is an internal sorting algorithm in SfePy for the conn array? I still don't understand why this would lead to problems in Comsol though...
I was thinking more about that nodal ordering (when wrong, it causes negative volume elements and other weird errors).
True, I think you are very right to consider nodal ordering. I checked the SfePy node ordering at [2] against the node ordering described in the Comsol documentation, so that's how I arrived at the values in the code. I think it's okay, but perhaps I made an error. Do you have access to the Comsol documentation? If not, maybe I can send you the relevant section offline. :)
Here's an example to clarify the problem:
./script/convert_mesh.py meshes/various_formats/comsol_tri.txt comsol_tri2.txt diff meshes/various_formats/comsol_tri.txt comsol_tri2.txt
I can see only whitespace differences in the order of elements (trinagles). Do you see something different?
Ooops, you are right. I didn't check the result of the diff command carefully in this case. I'll send a Comsol generated mesh which shows the difference. I think it may only be obvious for the 2_4 and 3_8 elements, since SfePy and Comsol share the node ordering for 2_3 and 3_4 elements.
After fixing my boundary conditions, it worked for 3_8 elements, so I think the node ordering is correct.
Ideally, I suppose the two meshes should match exactly. I'll try some more simple examples to see what the problem is in Comsol.
OK, but remember that sfepy does not use lower level entities in the mesh like edges, faces etc.
Ok, this could be another source of error. I belive in the comsol read code (which was based off the existing code for 2_3 elements :) ), it should only read the elements of the dimension of the mesh. Also, the write code should just write the SfePy conn arrays, so the lower level entities would be stripped as you say. I'm not sure if Comsol needs these lower level entities, or if it's smart enough to regenerate them from the higher level. I guess I need to do more testing :)
It looks like it isn't a problem for the lower level entities to be missing from the Comsol mesh.
Thanks again! Logan
>> [1] http://github.com/logansorenson/sfepy/tree/comsol_mesh [2] http://docs.sfepy.org/doc-devel/users_guide.html#fields
participants (2)
-
Logan Sorenson -
Robert Cimrman