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.