Ondrej Certik wrote:
Let's discuss how to best integrate it in sfepy. The main code is in:
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 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.