mesh class, automatic mesh generation, boundary conditions
Hi,
I put my code at:
http://code.google.com/p/sfepy/issues/detail?id=17
Let's discuss how to best integrate it in sfepy. The main code is in:
geom/meshutils.py
which converts to/from a lot of formats. It's quite long though and all in one class. My plan was to create a new class for each output/input format.
So let's create some basic mesh classes, for example based on the code in sfe/fem/mesh.py. Then I'll just subclass it, implement some output/input and that's it.
Another problem: how can I select some part of the geometry and assign a special boundary condition to it? In sfepy, as I understand it, it's handled by assigning a special number to each element (tetrahedron), but how can I generate such a mesh? It's not a business of sfepy. But generally I need to create a geometry (for example in gmsh), tell gmsh to mark some surface with a number. Then it is passed to tetgen, that is clever enough to assign this number to each element in the output. So all I need is to parse the output of tetgen and print the element numbers to a file for example.
Sometimes, I not only need the element IDs, but I also need the set of nodes sitting at a surface. All these features are implemented in the patch attached to the issue 17.
In my older FEM code, I simply read this file and assigned a correct BC to the elements in this file. How is this handled by sfepy?
I think sfepy can do some things that is in the patch, but probably cannot do all of them. So let's merge it. I am waiting for your suggestions and ideas. ;)
Ondrej
Ondrej Certik wrote:
Hi,
I put my code at:
Great, I will look at it.
Let's discuss how to best integrate it in sfepy. The main code is in:
geom/meshutils.py
which converts to/from a lot of formats. It's quite long though and all in one class. My plan was to create a new class for each output/input format.
To have transparent read support of various formats, I have created the meshio.py file (sfe.fem.meshio) - there are curently two classes, for medit (.mesh) and for legacy VTK files. I suggest you split your class and put a class for each format in there. Or I may do it, but not today, I fear. I will atleast document the expected return value of the read() method of those classes.
So let's create some basic mesh classes, for example based on the code in sfe/fem/mesh.py. Then I'll just subclass it, implement some output/input and that's it.
See above. What is needed is only a class with read() and write() (this one is not used anywhere yet) methods. The Mesh class in sfe/fem/mesh.py automatically selects the 'io' class then.
Another problem: how can I select some part of the geometry and assign a special boundary condition to it? In sfepy, as I understand it, it's handled by assigning a special number to each element (tetrahedron), but how can I generate such a mesh? It's not a business of sfepy. But generally I need to create a geometry (for example in gmsh), tell gmsh to mark some surface with a number. Then it is passed to tetgen, that is clever enough to assign this number to each element in the output. So all I need is to parse the output of tetgen and print the element numbers to a file for example.
Sometimes, I not only need the element IDs, but I also need the set of nodes sitting at a surface. All these features are implemented in the patch attached to the issue 17.
In my older FEM code, I simply read this file and assigned a correct BC to the elements in this file. How is this handled by sfepy?
Short answer: regions :-)
True, you can select elements by their id (the special number you mention), but there are many other ways
- select nodes by coordinates: region_03 = { 'name' : 'Gamma_Left', 'select' : 'nodes in (x < 0.00001)', }
- nodes of surface + subtracting/adding other regions: region_0 = { 'name' : 'Walls', 'select' : 'nodes of surface -n (r.Outlet +n r.Inlet)', 'canCells' : False, }
- ...
I think sfepy can do some things that is in the patch, but probably cannot do all of them. So let's merge it. I am waiting for your suggestions and ideas. ;)
I have not seen your patch yet, but the ideas above apply anyway :)
thanks for contributing to SfePy! r.
Let's discuss how to best integrate it in sfepy. The main code is in:
geom/meshutils.py
which converts to/from a lot of formats. It's quite long though and all in one class. My plan was to create a new class for each output/input format.
To have transparent read support of various formats, I have created the meshio.py file (sfe.fem.meshio) - there are curently two classes, for medit (.mesh) and for legacy VTK files. I suggest you split your class and put a class for each format in there. Or I may do it, but not today, I fear. I will atleast document the expected return value of the read() method of those classes.
This is all I need. Maybe even a new python file for each format? I.e. creating a new module "sfe.fem.io" and implement all the classes in there as separate files? If you are ok with that, I'll do it.
However, it's not that simple. No subclass in meshio.py implements the "write" method, this is all implemented in:
sfe/base/ioutils.py
There should imho be just one code (all in meshio.py?). What I did (see my patch), is, that the write methods accept an optinal keyword argument specifying the solution (scalar, vectors, or tensors, or both/all of it) and if the argument is present, the "write" method puts the solution together with the mesh into the file (if the format supports it).
My idea is to have one .py file for each format (for example in sfe/fem/io dir?) that implements everything there is to this format - reading mesh, writing mesh, writing a solution, so that it's not scattered all over sfepy. Do you agree? Are there any pitfalls regarding the sfe/base/ioutils.py file?
So let's create some basic mesh classes, for example based on the code in sfe/fem/mesh.py. Then I'll just subclass it, implement some output/input and that's it.
See above. What is needed is only a class with read() and write() (this one is not used anywhere yet) methods. The Mesh class in sfe/fem/mesh.py automatically selects the 'io' class then.
It's a little more complex, see above.
Another problem: how can I select some part of the geometry and assign a special boundary condition to it? In sfepy, as I understand it, it's handled by assigning a special number to each element (tetrahedron), but how can I generate such a mesh? It's not a business of sfepy. But generally I need to create a geometry (for example in gmsh), tell gmsh to mark some surface with a number. Then it is passed to tetgen, that is clever enough to assign this number to each element in the output. So all I need is to parse the output of tetgen and print the element numbers to a file for example.
Sometimes, I not only need the element IDs, but I also need the set of nodes sitting at a surface. All these features are implemented in the patch attached to the issue 17.
In my older FEM code, I simply read this file and assigned a correct BC to the elements in this file. How is this handled by sfepy?
Short answer: regions :-)
True, you can select elements by their id (the special number you mention), but there are many other ways
- select nodes by coordinates: region_03 = { 'name' : 'Gamma_Left', 'select' : 'nodes in (x < 0.00001)', }
- nodes of surface + subtracting/adding other regions: region_0 = { 'name' : 'Walls', 'select' : 'nodes of surface -n (r.Outlet +n r.Inlet)', 'canCells' : False, }
Excellent, regions is all I need. I am able to specify regions in gmesh, and it is preserved by tetgen in the mesh. So then it should easily work in sfepy even now. Awesome.
Ondrej
Ondrej Certik wrote:
Let's discuss how to best integrate it in sfepy. The main code is in:
geom/meshutils.py
which converts to/from a lot of formats. It's quite long though and all in one class. My plan was to create a new class for each output/input format. To have transparent read support of various formats, I have created the meshio.py file (sfe.fem.meshio) - there are curently two classes, for medit (.mesh) and for legacy VTK files. I suggest you split your class and put a class for each format in there. Or I may do it, but not today, I fear. I will atleast document the expected return value of the read() method of those classes.
This is all I need. Maybe even a new python file for each format? I.e. creating a new module "sfe.fem.io" and implement all the classes in there as separate files? If you are ok with that, I'll do it.
However, it's not that simple. No subclass in meshio.py implements the "write" method, this is all implemented in:
sfe/base/ioutils.py
sfe/base/ioutils.py sucks, as it is probably the oldest part of the code. it will contain only the low-level reading/writing functions, all the other belong to meshio.py. I just have not moved the code yet, because I wanted to see your code and its implications first. And I was lazy. :)
There should imho be just one code (all in meshio.py?). What I did (see my patch), is, that the write methods accept an optinal keyword argument specifying the solution (scalar, vectors, or tensors, or both/all of it) and if the argument is present, the "write" method puts the solution together with the mesh into the file (if the format supports it).
Sure, I do the same. The functions like ioutils.writeVTK() accept the 'out' argument which is a structure holding the solution, as returned by ProblemDefinition.stateToOutput( .. ). See also schroedinger.py :)
My idea is to have one .py file for each format (for example in sfe/fem/io dir?) that implements everything there is to this format - reading mesh, writing mesh, writing a solution, so that it's not scattered all over sfepy. Do you agree? Are there any pitfalls regarding the sfe/base/ioutils.py file?
Well, it depends on how many and how big those read/write classes are going to be. I can bear having 3-4 in one file, but it will probably grow beyond that... So let's do the split, but let me first think about how to deal with the high-level writing functions from ioutils.py. I will move them (probably) to meshio.py classes, and then we may split the file.
So let's create some basic mesh classes, for example based on the code in sfe/fem/mesh.py. Then I'll just subclass it, implement some output/input and that's it. See above. What is needed is only a class with read() and write() (this one is not used anywhere yet) methods. The Mesh class in sfe/fem/mesh.py automatically selects the 'io' class then.
It's a little more complex, see above.
Yep.
r.
sfe/base/ioutils.py sucks, as it is probably the oldest part of the code. it will contain only the low-level reading/writing functions, all the other belong to meshio.py. I just have not moved the code yet, because I wanted to see your code and its implications first. And I was lazy. :)
My implemenation is ugly. It does the job though.
My idea is to have one .py file for each format (for example in sfe/fem/io dir?) that implements everything there is to this format - reading mesh, writing mesh, writing a solution, so that it's not scattered all over sfepy. Do you agree? Are there any pitfalls regarding the sfe/base/ioutils.py file?
Well, it depends on how many and how big those read/write classes are going to be. I can bear having 3-4 in one file, but it will probably grow beyond that... So let's do the split, but let me first think about
Yep.
how to deal with the high-level writing functions from ioutils.py. I will move them (probably) to meshio.py classes, and then we may split the file.
Cool. So should I wait with the refactoring? I'll be working on this today and over the weekend. So if you won't be around, I'll try to do it as best as I can and send you a patch, so that on Monday you can review it/apply it. BTW, I won't be available on Monday through Thursday next week.
Ondrej
Ondrej Certik wrote:
how to deal with the high-level writing functions from ioutils.py. I will move them (probably) to meshio.py classes, and then we may split the file.
Cool. So should I wait with the refactoring? I'll be working on this today and over the weekend. So if you won't be around, I'll try to do it as best as I can and send you a patch, so that on Monday you can review it/apply it. BTW, I won't be available on Monday through Thursday next week.
If you leave on Monday, then it would be better if you work on it now. :)
Make your MeshIO.read() in the spirit of what is already there. The write functions I am now working on will have probably the following arguments: (self, fileName, mesh, out), where out is the output Struct instance I talked about. I think I will be able to integrate your code even if we proceed in parallel.
thanks! r.
On Feb 8, 2008 1:38 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ondrej Certik wrote:
how to deal with the high-level writing functions from ioutils.py. I will move them (probably) to meshio.py classes, and then we may split the file.
Cool. So should I wait with the refactoring? I'll be working on this today and over the weekend. So if you won't be around, I'll try to do it as best as I can and send you a patch, so that on Monday you can review it/apply it. BTW, I won't be available on Monday through Thursday next week.
If you leave on Monday, then it would be better if you work on it now. :)
Make your MeshIO.read() in the spirit of what is already there. The write functions I am now working on will have probably the following arguments: (self, fileName, mesh, out), where out is the output Struct instance I talked about. I think I will be able to integrate your code even if we proceed in parallel.
I need to finish one arcticle first, so I'll get to sfepy later today. O.
On Feb 8, 2008 3:28 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ondrej Certik wrote:
I need to finish one arcticle first, so I'll get to sfepy later today.
Good, it gave me time to make some changes :) Now the *MeshIO.write() methods work, though the medit one is not finished. But tests pass.
So I'll adapt my classes to the sfe/fem/meshio.py. And then refactor it into sfe/mesh/io dir, because this file is already getting big and it will get much bigger.
Ondrej
Ondrej Certik wrote:
On Feb 8, 2008 3:28 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
Ondrej Certik wrote:
I need to finish one arcticle first, so I'll get to sfepy later today. Good, it gave me time to make some changes :) Now the *MeshIO.write() methods work, though the medit one is not finished. But tests pass.
So I'll adapt my classes to the sfe/fem/meshio.py. And then refactor it into sfe/mesh/io dir, because this file is already getting big and it will get much bigger.
I have thought of another thing: use the io classes as plugins = collect them automatically in some specified directory. This directory should be outside of the sources in sfe/, similar to what the 'eldesc' directory is. Of course the basic io classes should be included in the sources as they are already (obviously I am here for the two that are already done: medit and vtk + your favorites). In this way, adding/testing new io classes would be really simple - just add the file into some ioplugins directory.
Anyway the refactoring into 'a file per io class' is useful.
r.
participants (2)
-
Ondrej Certik -
Robert Cimrman