Initial basic read support for MED file format (salome platform and pythonocc)
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
Best regards, Logan
[1] http://www.salome-platform.org [2] http://www.pythonocc.org
-- 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 04/28/10 22:01, Logan Sorenson wrote:
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
Nice! It works fine here. Do you want me to apply it now, or after you add more functionality?
One detail - I had used the comment markup like
## # c: 05.02.2008
at the ancient times before I used any version control system at all and it leaked into the repository only by inertia. There is no need for this now, and I slowly remove it when updating/fixing some part of the code.
It is a good indicator which parts are old, usually buggy, undocumented, and need a refit :-)
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
I can handle French (sort of), if you do not find the English version.
It's cool to support a [1], [2] format directly.
Thanks! r.
[1] http://www.salome-platform.org [2] http://www.pythonocc.org
-- 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 Thu, Apr 29, 2010 at 5:20 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Hi Logan,
On 04/28/10 22:01, Logan Sorenson wrote:
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
Nice! It works fine here. Do you want me to apply it now, or after you add more functionality?
I'm going to be doing some more work to get it more robust and support more features of the MED format. On the other hand, I guess it doesn't affect any other parts of sfepy, so it probably wouldn't hurt to check it in. Do you think we should wait until it supports more features?
One detail - I had used the comment markup like
## # c: 05.02.2008
at the ancient times before I used any version control system at all and it leaked into the repository only by inertia. There is no need for this now, and I slowly remove it when updating/fixing some part of the code.
It is a good indicator which parts are old, usually buggy, undocumented, and need a refit :-)
Ok, it's no problem to remove it if it is no longer recommended. :)
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
I can handle French (sort of), if you do not find the English version.
Ok, I put the French document at [3], along with the google docs English translation (text only) at [4]. I can decipher most of it, but one thing I'm having problems with is the distinction between "Maillage" and "Maille". I'm guessing "Maillage" is the mesh as a whole while a "Maille" is the element connectivities.
Also, this documentation seems to be for the API rather than the file format itself. Do you think it would be advantageous to use the APIs provided by salome platform, or would it be better just to implement our own version based off the file format? So far, I think the latter has the advantage of simplicity. There is a nice high-level description of the MED layers at [5].
One question I have is if SfePy supports multiple dimensional meshes at once. It seems the MED format also contains the face and edge elements for a 3D mesh. What would happen if we grab all of these meshes? I'll give it a try... :)
It's cool to support a [1], [2] format directly.
Thanks! r.
No problem! More questions to follow... Logan
[1] http://www.salome-platform.org [2] http://www.pythonocc.org [3] http://groups.google.com/group/sfepy-devel/web/NOTE_HI_26_03_012_A.pdf [4] http://groups.google.com/group/sfepy-devel/web/NOTE_HI.txt [5] http://www.salome-platform.org/about/med
-- 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,
On Thu, Apr 29, 2010 at 3:37 PM, Logan Sorenson <logan.s...@gmail.com> wrote:
Hi Robert,
On Thu, Apr 29, 2010 at 5:20 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Hi Logan,
On 04/28/10 22:01, Logan Sorenson wrote:
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
Nice! It works fine here. Do you want me to apply it now, or after you add more functionality?
I'm going to be doing some more work to get it more robust and support more features of the MED format. On the other hand, I guess it doesn't affect any other parts of sfepy, so it probably wouldn't hurt to check it in. Do you think we should wait until it supports more features?
Ok, I put in some work, now it should (in theory - see below) support all MED elements except for general polygons and polyhedrons. Also, I made it grab the mesh automatically without relying on the name being Mesh_1. It still only looks at the first mesh in the MED file, but we could easily roll it into a loop if we think it's needed. The code is now in the med branch on my github repository at [6]. Feel free to give it a try and see if there are any bugs! ;)
One detail - I had used the comment markup like
## # c: 05.02.2008
at the ancient times before I used any version control system at all and it leaked into the repository only by inertia. There is no need for this now, and I slowly remove it when updating/fixing some part of the code.
It is a good indicator which parts are old, usually buggy, undocumented, and need a refit :-)
Ok, it's no problem to remove it if it is no longer recommended. :)
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
I can handle French (sort of), if you do not find the English version.
Ok, I put the French document at [3], along with the google docs English translation (text only) at [4]. I can decipher most of it, but one thing I'm having problems with is the distinction between "Maillage" and "Maille". I'm guessing "Maillage" is the mesh as a whole while a "Maille" is the element connectivities.
Also, this documentation seems to be for the API rather than the file format itself. Do you think it would be advantageous to use the APIs provided by salome platform, or would it be better just to implement our own version based off the file format? So far, I think the latter has the advantage of simplicity. There is a nice high-level description of the MED layers at [5].
One question I have is if SfePy supports multiple dimensional meshes at once. It seems the MED format also contains the face and edge elements for a 3D mesh. What would happen if we grab all of these meshes? I'll give it a try... :)
Right now, I'm grabbing all the elements in the MED file (assuming they are compatible with SfePy). postproc.py doesn't seem to complain about mixed 2D and 3D elements, but I've yet to try an actual calculation with the mesh. Is it a problem to mix the dimensionalities of the elements?
Where can I find what element (descs) are supported by SfePy? Following is the dictionary which maps MED element types to SfePy descs. I have certain lines commented out because postproc.py was throwing a KeyError, so I was assuming these types are not implemented yet. Also, I think the 1D elements are not supported by SfePy, correct? Is there support for quad order elements (e.g., 20 node hexahedral)?
# Dict to map MED element names to SfePy descs
#NOTE: The commented lines are elements which
# produce KeyError in SfePy
med_descs = {
'TE4' : '3_4',
#'T10' : '3_10',
#'PY5' : '3_5',
#'P13' : '3_13',
'HE8' : '3_8',
#'H20' : '3_20',
#'PE6' : '3_6',
#'P15' : '3_15',
#TODO: Polyhedrons (POE) - need special handling
'TR3' : '2_3',
#'TR6' : '2_6',
'QU4' : '2_4',
#'QU8' : '2_8',
#TODO: Polygons (POG) - need special handling
#'SE2' : '1_2',
#'SE3' : '1_3',
}Ok, I'm off to try some calculations. Thanks, and happy meshing! :)
Logan
[1] http://www.salome-platform.org [2] http://www.pythonocc.org [3] http://groups.google.com/group/sfepy-devel/web/NOTE_HI_26_03_012_A.pdf [4] http://groups.google.com/group/sfepy-devel/web/NOTE_HI.txt [5] http://www.salome-platform.org/about/med
[6] http://github.com/logansorenson/sfepy/tree/med
-- 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.
On Thu, Apr 29, 2010 at 8:49 PM, Logan Sorenson <logan.s...@gmail.com> wrote:
Hi,
On Thu, Apr 29, 2010 at 3:37 PM, Logan Sorenson <logan.s...@gmail.com> wrote:
Hi Robert,
On Thu, Apr 29, 2010 at 5:20 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Hi Logan,
On 04/28/10 22:01, Logan Sorenson wrote:
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
Nice! It works fine here. Do you want me to apply it now, or after you add more functionality?
I'm going to be doing some more work to get it more robust and support more features of the MED format. On the other hand, I guess it doesn't affect any other parts of sfepy, so it probably wouldn't hurt to check it in. Do you think we should wait until it supports more features?
Ok, I put in some work, now it should (in theory - see below) support all MED elements except for general polygons and polyhedrons. Also, I made it grab the mesh automatically without relying on the name being Mesh_1. It still only looks at the first mesh in the MED file, but we could easily roll it into a loop if we think it's needed. The code is now in the med branch on my github repository at [6]. Feel free to give it a try and see if there are any bugs! ;)
One detail - I had used the comment markup like
## # c: 05.02.2008
at the ancient times before I used any version control system at all and it leaked into the repository only by inertia. There is no need for this now, and I slowly remove it when updating/fixing some part of the code.
It is a good indicator which parts are old, usually buggy, undocumented, and need a refit :-)
Ok, it's no problem to remove it if it is no longer recommended. :)
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
I can handle French (sort of), if you do not find the English version.
Ok, I put the French document at [3], along with the google docs English translation (text only) at [4]. I can decipher most of it, but one thing I'm having problems with is the distinction between "Maillage" and "Maille". I'm guessing "Maillage" is the mesh as a whole while a "Maille" is the element connectivities.
Also, this documentation seems to be for the API rather than the file format itself. Do you think it would be advantageous to use the APIs provided by salome platform, or would it be better just to implement our own version based off the file format? So far, I think the latter has the advantage of simplicity. There is a nice high-level description of the MED layers at [5].
One question I have is if SfePy supports multiple dimensional meshes at once. It seems the MED format also contains the face and edge elements for a 3D mesh. What would happen if we grab all of these meshes? I'll give it a try... :)
Right now, I'm grabbing all the elements in the MED file (assuming they are compatible with SfePy). postproc.py doesn't seem to complain about mixed 2D and 3D elements, but I've yet to try an actual calculation with the mesh. Is it a problem to mix the dimensionalities of the elements?
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
Where can I find what element (descs) are supported by SfePy? Following is the dictionary which maps MED element types to SfePy descs. I have certain lines commented out because postproc.py was throwing a KeyError, so I was assuming these types are not implemented yet. Also, I think the 1D elements are not supported by SfePy, correct? Is there support for quad order elements (e.g., 20 node hexahedral)?
# Dict to map MED element names to SfePy descs #NOTE: The commented lines are elements which # produce KeyError in SfePy med_descs = { 'TE4' : '3_4', #'T10' : '3_10', #'PY5' : '3_5', #'P13' : '3_13', 'HE8' : '3_8', #'H20' : '3_20', #'PE6' : '3_6', #'P15' : '3_15', #TODO: Polyhedrons (POE) - need special handling 'TR3' : '2_3', #'TR6' : '2_6', 'QU4' : '2_4', #'QU8' : '2_8', #TODO: Polygons (POG) - need special handling #'SE2' : '1_2', #'SE3' : '1_3', }
Ok, I'm off to try some calculations. Thanks, and happy meshing! :)
Logan
[1] http://www.salome-platform.org [2] http://www.pythonocc.org [3] http://groups.google.com/group/sfepy-devel/web/NOTE_HI_26_03_012_A.pdf [4] http://groups.google.com/group/sfepy-devel/web/NOTE_HI.txt [5] http://www.salome-platform.org/about/med
-- 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.
<snip>
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
Here is the mesh and sfepy problem description file for those interested.
Best, 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.
On 04/30/10 07:28, Logan Sorenson wrote:
On Thu, Apr 29, 2010 at 8:49 PM, Logan Sorenson <logan.s...@gmail.com> wrote:
Hi,
On Thu, Apr 29, 2010 at 3:37 PM, Logan Sorenson <logan.s...@gmail.com> wrote:
Hi Robert,
On Thu, Apr 29, 2010 at 5:20 AM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:
Hi Logan,
On 04/28/10 22:01, Logan Sorenson wrote:
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
Nice! It works fine here. Do you want me to apply it now, or after you add more functionality?
I'm going to be doing some more work to get it more robust and support more features of the MED format. On the other hand, I guess it doesn't affect any other parts of sfepy, so it probably wouldn't hurt to check it in. Do you think we should wait until it supports more features?
Ok, I put in some work, now it should (in theory - see below) support all MED elements except for general polygons and polyhedrons. Also, I made it grab the mesh automatically without relying on the name being Mesh_1. It still only looks at the first mesh in the MED file, but we could easily roll it into a loop if we think it's needed. The code is now in the med branch on my github repository at [6]. Feel free to give it a try and see if there are any bugs! ;)
One detail - I had used the comment markup like
## # c: 05.02.2008
at the ancient times before I used any version control system at all and it leaked into the repository only by inertia. There is no need for this now, and I slowly remove it when updating/fixing some part of the code.
It is a good indicator which parts are old, usually buggy, undocumented, and need a refit :-)
Ok, it's no problem to remove it if it is no longer recommended. :)
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
I can handle French (sort of), if you do not find the English version.
Ok, I put the French document at [3], along with the google docs English translation (text only) at [4]. I can decipher most of it, but one thing I'm having problems with is the distinction between "Maillage" and "Maille". I'm guessing "Maillage" is the mesh as a whole while a "Maille" is the element connectivities.
Also, this documentation seems to be for the API rather than the file format itself. Do you think it would be advantageous to use the APIs provided by salome platform, or would it be better just to implement our own version based off the file format? So far, I think the latter has the advantage of simplicity. There is a nice high-level description of the MED layers at [5].
One question I have is if SfePy supports multiple dimensional meshes at once. It seems the MED format also contains the face and edge elements for a 3D mesh. What would happen if we grab all of these meshes? I'll give it a try... :)
Right now, I'm grabbing all the elements in the MED file (assuming they are compatible with SfePy). postproc.py doesn't seem to complain about mixed 2D and 3D elements, but I've yet to try an actual calculation with the mesh. Is it a problem to mix the dimensionalities of the elements?
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
I merged your branch and updated the class for not reading entities of other dimension than the space dimension, see my github site [7]. I think it would be fine to be able to exploit somehow those additional information in a mesh file, but I do not know how to do it yet (without breaking many things).
Where can I find what element (descs) are supported by SfePy? Following is the dictionary which maps MED element types to SfePy descs. I have certain lines commented out because postproc.py was throwing a KeyError, so I was assuming these types are not implemented yet. Also, I think the 1D elements are not supported by SfePy, correct? Is there support for quad order elements (e.g., 20 node hexahedral)?
See [8], section on fields. You got it right :)
# Dict to map MED element names to SfePy descs #NOTE: The commented lines are elements which # produce KeyError in SfePy med_descs = { 'TE4' : '3_4', #'T10' : '3_10', #'PY5' : '3_5', #'P13' : '3_13', 'HE8' : '3_8', #'H20' : '3_20', #'PE6' : '3_6', #'P15' : '3_15', #TODO: Polyhedrons (POE) - need special handling 'TR3' : '2_3', #'TR6' : '2_6', 'QU4' : '2_4', #'QU8' : '2_8', #TODO: Polygons (POG) - need special handling #'SE2' : '1_2', #'SE3' : '1_3', }Ok, I'm off to try some calculations. Thanks, and happy meshing! :)
:)
cheers, r.
[1] http://www.salome-platform.org [2] http://www.pythonocc.org [3] http://groups.google.com/group/sfepy-devel/web/NOTE_HI_26_03_012_A.pdf [4] http://groups.google.com/group/sfepy-devel/web/NOTE_HI.txt [5] http://www.salome-platform.org/about/med [6] http://github.com/logansorenson/sfepy/tree/med
[7] http://github.com/rc/sfepy [8] http://docs.sfepy.org/doc-devel/users_guide.html#problem-description-file
-- 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.
On Fri, Apr 30, 2010 at 9:39 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
On 04/30/10 07:28, Logan Sorenson wrote:
On Thu, Apr 29, 2010 at 8:49 PM, Logan Sorenson <logan.s...@gmail.com> wrote:
Hi,
On Thu, Apr 29, 2010 at 3:37 PM, Logan Sorenson <logan.s...@gmail.com> wrote:
Hi Robert,
On Thu, Apr 29, 2010 at 5:20 AM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:
Hi Logan,
On 04/28/10 22:01, Logan Sorenson wrote:
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
Nice! It works fine here. Do you want me to apply it now, or after you add more functionality?
I'm going to be doing some more work to get it more robust and support more features of the MED format. On the other hand, I guess it doesn't affect any other parts of sfepy, so it probably wouldn't hurt to check it in. Do you think we should wait until it supports more features?
Ok, I put in some work, now it should (in theory - see below) support all MED elements except for general polygons and polyhedrons. Also, I made it grab the mesh automatically without relying on the name being Mesh_1. It still only looks at the first mesh in the MED file, but we could easily roll it into a loop if we think it's needed. The code is now in the med branch on my github repository at [6]. Feel free to give it a try and see if there are any bugs! ;)
One detail - I had used the comment markup like
## # c: 05.02.2008
at the ancient times before I used any version control system at all and it leaked into the repository only by inertia. There is no need for this now, and I slowly remove it when updating/fixing some part of the code.
It is a good indicator which parts are old, usually buggy, undocumented, and need a refit :-)
Ok, it's no problem to remove it if it is no longer recommended. :)
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
I can handle French (sort of), if you do not find the English version.
Ok, I put the French document at [3], along with the google docs English translation (text only) at [4]. I can decipher most of it, but one thing I'm having problems with is the distinction between "Maillage" and "Maille". I'm guessing "Maillage" is the mesh as a whole while a "Maille" is the element connectivities.
Also, this documentation seems to be for the API rather than the file format itself. Do you think it would be advantageous to use the APIs provided by salome platform, or would it be better just to implement our own version based off the file format? So far, I think the latter has the advantage of simplicity. There is a nice high-level description of the MED layers at [5].
One question I have is if SfePy supports multiple dimensional meshes at once. It seems the MED format also contains the face and edge elements for a 3D mesh. What would happen if we grab all of these meshes? I'll give it a try... :)
Right now, I'm grabbing all the elements in the MED file (assuming they are compatible with SfePy). postproc.py doesn't seem to complain about mixed 2D and 3D elements, but I've yet to try an actual calculation with the mesh. Is it a problem to mix the dimensionalities of the elements?
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
I merged your branch and updated the class for not reading entities of other dimension than the space dimension, see my github site [7]. I think it would be fine to be able to exploit somehow those additional information in a mesh file, but I do not know how to do it yet (without breaking many things).
Yes, I would place it as a nice to have, rather than something that is needed immediately. :)
Where can I find what element (descs) are supported by SfePy? Following is the dictionary which maps MED element types to SfePy descs. I have certain lines commented out because postproc.py was throwing a KeyError, so I was assuming these types are not implemented yet. Also, I think the 1D elements are not supported by SfePy, correct? Is there support for quad order elements (e.g., 20 node hexahedral)?
See [8], section on fields. You got it right :)
Ah, ok, I needed to RTM ;) Another nice to have would be quadratic element support (i.e., midside nodes) for the types of elements currently supported by SfePy. Not sure how much work would be involved there. I'll add to the issues list.
# Dict to map MED element names to SfePy descs #NOTE: The commented lines are elements which # produce KeyError in SfePy med_descs = { 'TE4' : '3_4', #'T10' : '3_10', #'PY5' : '3_5', #'P13' : '3_13', 'HE8' : '3_8', #'H20' : '3_20', #'PE6' : '3_6', #'P15' : '3_15', #TODO: Polyhedrons (POE) - need special handling 'TR3' : '2_3', #'TR6' : '2_6', 'QU4' : '2_4', #'QU8' : '2_8', #TODO: Polygons (POG) - need special handling #'SE2' : '1_2', #'SE3' : '1_3', }
Ok, I'm off to try some calculations. Thanks, and happy meshing! :)
:)
cheers, r.
Cheers! Logan
[1] http://www.salome-platform.org [2] http://www.pythonocc.org
[3] http://groups.google.com/group/sfepy-devel/web/NOTE_HI_26_03_012_A.pdf [4] http://groups.google.com/group/sfepy-devel/web/NOTE_HI.txt [5] http://www.salome-platform.org/about/med
[7] http://github.com/rc/sfepy [8] http://docs.sfepy.org/doc-devel/users_guide.html#problem-description-file
-- 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.
On 04/30/10 17:20, Logan Sorenson wrote:
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
I merged your branch and updated the class for not reading entities of other dimension than the space dimension, see my github site [7]. I think it would be fine to be able to exploit somehow those additional information in a mesh file, but I do not know how to do it yet (without breaking many things).
Yes, I would place it as a nice to have, rather than something that is needed immediately. :)
At least the code should not segfault :)
Where can I find what element (descs) are supported by SfePy? Following is the dictionary which maps MED element types to SfePy descs. I have certain lines commented out because postproc.py was throwing a KeyError, so I was assuming these types are not implemented yet. Also, I think the 1D elements are not supported by SfePy, correct? Is there support for quad order elements (e.g., 20 node hexahedral)?
See [8], section on fields. You got it right :)
Ah, ok, I needed to RTM ;) Another nice to have would be quadratic element support (i.e., midside nodes) for the types of elements currently supported by SfePy. Not sure how much work would be involved there. I'll add to the issues list.
We support P2 elements, but the mid-edge nodes are generated at centres of the straight edges. This part of the code is really old and needs major refitting.
I would like to be able to use e.g. hermes for adaptivity. The problem is that I do not know yet a solution that would work with all the terms we have. SfePy is reasonably fast, because all the elements (in an element group) are the same - then it is possible to pass a whole chunk of them to C for computing element contributions. Adaptivity is in direct contradiction with this requirement - every element is, in general, unique with various number of degrees of freedom, integration order etc.
So we need a new C(++) structure replacing FMField to hold the element data - something with fast random access (indexing), but dynamic to allow different shape of each element. This also disqualifies numpy arrays as the container on the Python side... So this new structure would have to be a new Python class.
Anyway, the first step is to decouple the high-level API (problem description, etc). from the FE engine used. I am slowly working in this direction, but it's a kind of moving unknown target.
r.
> [1] http://www.salome-platform.org > [2] http://www.pythonocc.org
[3] http://groups.google.com/group/sfepy-devel/web/NOTE_HI_26_03_012_A.pdf [4] http://groups.google.com/group/sfepy-devel/web/NOTE_HI.txt [5] http://www.salome-platform.org/about/med
[7] http://github.com/rc/sfepy [8] http://docs.sfepy.org/doc-devel/users_guide.html#problem-description-file
-- 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.
On 04/30/10 17:54, Robert Cimrman wrote:
On 04/30/10 17:20, Logan Sorenson wrote:
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
I merged your branch and updated the class for not reading entities of other dimension than the space dimension, see my github site [7]. I think it would be fine to be able to exploit somehow those additional information in a mesh file, but I do not know how to do it yet (without breaking many things).
Yes, I would place it as a nice to have, rather than something that is needed immediately. :)
At least the code should not segfault :)
Where can I find what element (descs) are supported by SfePy? Following is the dictionary which maps MED element types to SfePy descs. I have certain lines commented out because postproc.py was throwing a KeyError, so I was assuming these types are not implemented yet. Also, I think the 1D elements are not supported by SfePy, correct? Is there support for quad order elements (e.g., 20 node hexahedral)?
See [8], section on fields. You got it right :)
Ah, ok, I needed to RTM ;) Another nice to have would be quadratic element support (i.e., midside nodes) for the types of elements currently supported by SfePy. Not sure how much work would be involved there. I'll add to the issues list.
We support P2 elements, but the mid-edge nodes are generated at centres of the straight edges. This part of the code is really old and needs major refitting.
I would like to be able to use e.g. hermes for adaptivity. The problem is that I do not know yet a solution that would work with all the terms we have. SfePy is reasonably fast, because all the elements (in an element group) are the same - then it is possible to pass a whole chunk of them to C for computing element contributions. Adaptivity is in direct contradiction with this requirement - every element is, in general, unique with various number of degrees of freedom, integration order etc.
So we need a new C(++) structure replacing FMField to hold the element data - something with fast random access (indexing), but dynamic to allow different shape of each element. This also disqualifies numpy arrays as the container on the Python side... So this new structure would have to be a new Python class.
Anyway, the first step is to decouple the high-level API (problem description, etc). from the FE engine used. I am slowly working in this direction, but it's a kind of moving unknown target.
To answer your question - I guess supporting also Q2 (tri-quadratic) elements and use curved quadratic edges defined in a mesh would not be that difficult...
But I prefer to solve this once and for all. :) On the other hand, a partial solution may reveal something needed to achieve the final goal.
r.
-- 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.
On Fri, Apr 30, 2010 at 12:18 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
On 04/30/10 17:54, Robert Cimrman wrote:
On 04/30/10 17:20, Logan Sorenson wrote:
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
I merged your branch and updated the class for not reading entities of other dimension than the space dimension, see my github site [7]. I think it would be fine to be able to exploit somehow those additional information in a mesh file, but I do not know how to do it yet (without breaking many things).
Yes, I would place it as a nice to have, rather than something that is needed immediately. :)
At least the code should not segfault :)
Where can I find what element (descs) are supported by SfePy? Following is the dictionary which maps MED element types to SfePy descs. I have certain lines commented out because postproc.py was throwing a KeyError, so I was assuming these types are not implemented yet. Also, I think the 1D elements are not supported by SfePy, correct? Is there support for quad order elements (e.g., 20 node hexahedral)?
See [8], section on fields. You got it right :)
Ah, ok, I needed to RTM ;) Another nice to have would be quadratic element support (i.e., midside nodes) for the types of elements currently supported by SfePy. Not sure how much work would be involved there. I'll add to the issues list.
We support P2 elements, but the mid-edge nodes are generated at centres of the straight edges. This part of the code is really old and needs major refitting.
I would like to be able to use e.g. hermes for adaptivity. The problem is that I do not know yet a solution that would work with all the terms we have. SfePy is reasonably fast, because all the elements (in an element group) are the same - then it is possible to pass a whole chunk of them to C for computing element contributions. Adaptivity is in direct contradiction with this requirement - every element is, in general, unique with various number of degrees of freedom, integration order etc.
So we need a new C(++) structure replacing FMField to hold the element data - something with fast random access (indexing), but dynamic to allow different shape of each element. This also disqualifies numpy arrays as the container on the Python side... So this new structure would have to be a new Python class.
Anyway, the first step is to decouple the high-level API (problem description, etc). from the FE engine used. I am slowly working in this direction, but it's a kind of moving unknown target.
To answer your question - I guess supporting also Q2 (tri-quadratic) elements and use curved quadratic edges defined in a mesh would not be that difficult...
But I prefer to solve this once and for all. :) On the other hand, a partial solution may reveal something needed to achieve the final goal.
Ok, I got a better understanding of these issues in SfePy. Thanks for sharing your insight!
I think then that supporting Q2 elements from the mesh is not necessary since Salome provides a means of automatically converting between Q2 and Q1 (is this the right notation?). I had forgotten about the automatic midside node generation in SfePy.
I agree then, we should concentrate on a longer term approach of separating the high-level stuff from the underlying FE engine. I'll start looking into how hermes works with adaptivity and their data structures. It would be cool to have the basic SfePy solver for speed and simplicity, but also have the option of additional solvers for adaptivity, etc. Definitely a complex issue, but a worthy target. :)
BTW, thanks for the fix of picking out just the elements of the dimensionality of the mesh. My brain was too tired last night to handle figuring it out!
Best, 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.
On 04/30/10 20:30, Logan Sorenson wrote:
On Fri, Apr 30, 2010 at 12:18 PM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:
On 04/30/10 17:54, Robert Cimrman wrote:
On 04/30/10 17:20, Logan Sorenson wrote:
Ok, I was able to run the poisson's example on an MED mesh! However, I had to comment out the 2D elements from the MED->SfePy desc translation dict below. I am getting a SEGFAULT when running with multiple dimension meshes. I suspect the mixed dimensionality of the mesh is overrunning some array bounds in the C code. I guess for now we can try to grab only 3D elements if they exist, and if not, grab 2D elements.
I merged your branch and updated the class for not reading entities of other dimension than the space dimension, see my github site [7]. I think it would be fine to be able to exploit somehow those additional information in a mesh file, but I do not know how to do it yet (without breaking many things).
Yes, I would place it as a nice to have, rather than something that is needed immediately. :)
At least the code should not segfault :)
> Where can I find what element (descs) are supported by SfePy? > Following is the dictionary which maps MED element types to SfePy > descs. I have certain lines commented out because postproc.py was > throwing a KeyError, so I was assuming these types are not implemented > yet. Also, I think the 1D elements are not supported by SfePy, > correct? Is there support for quad order elements (e.g., 20 node > hexahedral)?
See [8], section on fields. You got it right :)
Ah, ok, I needed to RTM ;) Another nice to have would be quadratic element support (i.e., midside nodes) for the types of elements currently supported by SfePy. Not sure how much work would be involved there. I'll add to the issues list.
We support P2 elements, but the mid-edge nodes are generated at centres of the straight edges. This part of the code is really old and needs major refitting.
I would like to be able to use e.g. hermes for adaptivity. The problem is that I do not know yet a solution that would work with all the terms we have. SfePy is reasonably fast, because all the elements (in an element group) are the same - then it is possible to pass a whole chunk of them to C for computing element contributions. Adaptivity is in direct contradiction with this requirement - every element is, in general, unique with various number of degrees of freedom, integration order etc.
So we need a new C(++) structure replacing FMField to hold the element data - something with fast random access (indexing), but dynamic to allow different shape of each element. This also disqualifies numpy arrays as the container on the Python side... So this new structure would have to be a new Python class.
Anyway, the first step is to decouple the high-level API (problem description, etc). from the FE engine used. I am slowly working in this direction, but it's a kind of moving unknown target.
To answer your question - I guess supporting also Q2 (tri-quadratic) elements and use curved quadratic edges defined in a mesh would not be that difficult...
But I prefer to solve this once and for all. :) On the other hand, a partial solution may reveal something needed to achieve the final goal.
Ok, I got a better understanding of these issues in SfePy. Thanks for sharing your insight!
I think then that supporting Q2 elements from the mesh is not necessary since Salome provides a means of automatically converting between Q2 and Q1 (is this the right notation?). I had forgotten about the automatic midside node generation in SfePy.
I guess you got it right. The P* family are the Langrange basis elements on simplex domains, while the Q* are the tensor product elements on rectangular domains. They are called tensor product as they are composed by a product of 1D Langrange elements along each axis, i.e. a complete base function N(x,y,z) is composed as N_x(x) N_y(y) N_z(z). So even Q1 is not linear (it is bilinear in 2D, trilinear in 3D).
I agree then, we should concentrate on a longer term approach of separating the high-level stuff from the underlying FE engine. I'll start looking into how hermes works with adaptivity and their data structures. It would be cool to have the basic SfePy solver for speed and simplicity, but also have the option of additional solvers for adaptivity, etc. Definitely a complex issue, but a worthy target. :)
To explore this, it is cubmersome to drag the C code along. We should, IMHO, have a pure Python implementation first. I had made some steps already - there is an experimental branch, where the Domain and Region classes are refactored, greatly simplified (no element groups!), using just basic Python classes (lists and dicts mostly). It is only about 4 times slower than the current code, that uses C functions to enumerate edges and faces, even for very large meshes, which is rather promising.
I work on that branch from time to time, but not very actively :]. I think I will rebase it to the current master, polish it a bit, a publish it at github, so that others can comment/improve on it. The difficult part awaits - refactoring Field, Variable, and fea.py - this is where the entanglement of various things occurs badly.
BTW, thanks for the fix of picking out just the elements of the dimensionality of the mesh. My brain was too tired last night to handle figuring it out!
Well, thanks for the patch!
r.
-- 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.
On 04/29/10 21:37, Logan Sorenson wrote:
Hi Robert,
On Thu, Apr 29, 2010 at 5:20 AM, Robert Cimrman<cimr...@ntc.zcu.cz> wrote:
Hi Logan,
On 04/28/10 22:01, Logan Sorenson wrote:
Hi All,
Please find attached a patch to sfepy/fem/meshio.py for basic read support for MED format meshes. I'm attaching the patch here since github seems to be down in the US. MED is the native mesh format for the very powerful open-source meshing tools salome [1] and pythonocc [2].
Actually, it is very incomplete, but seems to work with the provided example mesh (Mesh_1.med). I only tried loading the mesh with postproc.py, so I haven't run any calculations on it yet (I assume that should work ok). So far, it only supports 3D 8-node hexahedral elements, so I suppose it is more of an example of reading the format than an actual final production code. :) I hope it can be generalized to work with more MED meshes.
Nice! It works fine here. Do you want me to apply it now, or after you add more functionality?
I'm going to be doing some more work to get it more robust and support more features of the MED format. On the other hand, I guess it doesn't affect any other parts of sfepy, so it probably wouldn't hurt to check it in. Do you think we should wait until it supports more features?
No, I will apply the patch now. It's better to have something others can try.
One detail - I had used the comment markup like
## # c: 05.02.2008
at the ancient times before I used any version control system at all and it leaked into the repository only by inertia. There is no need for this now, and I slowly remove it when updating/fixing some part of the code.
It is a good indicator which parts are old, usually buggy, undocumented, and need a refit :-)
Ok, it's no problem to remove it if it is no longer recommended. :)
Yes. Well, we could easily remove all such occurrences, but I prefer to remove them after the related code gets updated...
I found some French documentation on MED in the source packages at [1]; I used google docs to translate it to English, so if someone wants a copy of that, let me know. I'm looking for a better English version of these docs.
I can handle French (sort of), if you do not find the English version.
Ok, I put the French document at [3], along with the google docs English translation (text only) at [4]. I can decipher most of it, but one thing I'm having problems with is the distinction between "Maillage" and "Maille". I'm guessing "Maillage" is the mesh as a whole while a "Maille" is the element connectivities.
Yes, maillage is definitely the mesh, and maille seems to be a kind of synonym, referring more to the connectivity.
If you have some particular questions, just ask. :)
Also, this documentation seems to be for the API rather than the file format itself. Do you think it would be advantageous to use the APIs provided by salome platform, or would it be better just to implement our own version based off the file format? So far, I think the latter has the advantage of simplicity. There is a nice high-level description of the MED layers at [5].
One question I have is if SfePy supports multiple dimensional meshes at once. It seems the MED format also contains the face and edge elements for a 3D mesh. What would happen if we grab all of these meshes? I'll give it a try... :)
Not for the moment, the code does not expect to find entities of lower dimension. We could support it somehow to allow another way of defining regions, though.
It's cool to support a [1], [2] format directly.
Thanks! r.
No problem! More questions to follow... Logan
cheers, r.
[1] http://www.salome-platform.org [2] http://www.pythonocc.org [3] http://groups.google.com/group/sfepy-devel/web/NOTE_HI_26_03_012_A.pdf [4] http://groups.google.com/group/sfepy-devel/web/NOTE_HI.txt [5] http://www.salome-platform.org/about/med
-- 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.
participants (2)
-
Logan Sorenson -
Robert Cimrman