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 : [email protected]
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
________________
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
