| Thread Previous • Date Previous • Date Next • Thread Next |
Hello Vaclav,Actually, I had the python wrapping in mind when I made TWrapper a plugin a few days ago.
You couldn't make a better suggestion at that point, thanks.However, I don't have much time in the comming weeks either, and I need to focus on few things.
The inifinite shear is half-way, there are still unidentified problems in it. I can commit something if you are curious, but I need a time-window where you can checkout and revert in a few hours because I don't want to break anything for others (shouldn't happen but who knows...). I've not touch it in the last days. Not speaking about things that need to be commented.
The TWrapper interface is not rich enough. If I could py-wrap as you suggest, somebody would come and tell me he wants access to another variable. For now, the priority is to decide what people need the most. The current code computes very few things (strain, volumes and porosity, in full domain or subdomains, on arbitrary time intervals) compared to what it could compute with just few more lines. I need more practical cases before deciding how/what to wrap (in your case, what do you need? why do you want to cycle over adjacent cells? is it real-time computation or post-processing?).
The minimalist approach would be to give numpy arrays to cells, i.e. four bodies ids, nothing more. It would be enough to compute strain per cell for instance, as you can use python to get the displacement of each body and integrate on the cell's contour.
Problem : with this minimalist approach (or even with the one you described, with acces to vertices and more), there is still no way to get incident cells on a vertex/edge/facet. "Traversing" the triangulation structure, and queries on connectivity, really needs to wrap most CGAL functions. This would be the maximalist way, but there are so many functions and so many possible traversing routes, that it is not something I'm considering at the moment (Sylvain Pion already started CGAL python wrapping, but not for regular triangulation http://cgal-python.gforge.inria.fr/).
Conclusion, I think I'll implement methods and give python access to them for now. Access to data will be done in another step perhaps.
Actually, my highest priority now is to compare triax and periTriax as planned. I'll test the triangulation code in periTriax. With very few changes (inserting wrapped points), it will compute strain in all cells except the ones crossing the period limit. With a bit more changes, it could consider all cells (duplicating shifted spheres and inserting them in the triangulation). Just to be sure : did you start thinking about it or should I start on my side? What do you plan in terms of triangulation? I'd be glad to help.
Last thing : we will commit Luc's files for capillary law. They are just big tables with numbers, used by the engine to interpolate capillary force. I think I'll zip them and commit them somewhere in trunk, with documentation and messages helping people to find and unzip them in /bin. What do you think of this solution?
Bruno
Hi Bruno, it would be nice to have access to triangulation and related data from python. There is (since around Christmas) way to construct numpy arrays from c++, so I think it would be nice to make a function that would return dictionary mapping names to arrays (numpy arrays are very memory-efficient in terms of avoiding copying data, and are a de-facto standard in python world). We support 1d/2d, Real/int arrays (can be extended, but I doubt anything beyond is useful here), the function would return python::dict (have a look at py/_eudoxos.cpp::137 (testNumpy), which creates 2 arrays and returns those) with something like: ret["vertices"]=2d Real array sized (nVertices x 3), where each column would have 3 Real numers with vertex coordinates (i.e. sphere position). ret["triangulation"]=2d int array sized (nTetrahedra x 4), each column containing 4 ints of the tetrahedron vertices. ret["strain"]=2d Real array sized (nTetrahedra x numberOfStrainComponents), each columns containing strain for the respective tetrahedron ret["verticesStrain"]=same, but averaged for each vertex (body position) from its neighbouring tetrahedra etc (I am not sure what your code can really compute). It would be up to the user to interpret those things right, i.e. know that "vertices" define vertices and so on. I can give some advices on that but unfortunately I don't have time to do that myself now. Cheers, Vaclav _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
-- _______________ Bruno Chareyre Associate Professor Grenoble INP Lab. 3SR BP 53 - 38041, Grenoble cedex 9 - France Tél : 33 4 56 52 86 21 Fax : 33 4 76 82 70 43 ________________
| Thread Previous • Date Previous • Date Next • Thread Next |
