In typical situations, TW and family will triangulate different scenes
stored in memory (snapshots of the same simulation) to get incremental
deformations between them. This is the reason of keeping a scene
pointer as parameter, even if it looks useless in current code. Ok
user can always switc
Very good. On my laptop TW.triangulate() + TW.computeVolumes() need
2.7sec for 100k spheres. May be to add this script to a examples?
A script probably needs a few imports and other things, and I didn't
take time to tune one.
The example in docstring is quite clear I think, but If you feel like
02.11.2010 19:30, Bruno Chareyre:
Not yet. But "CGAL needs 1.4sec for 100k spheres" is very good. This
is what CPU? And couldn't you give a some working script, such as
calculate the volume of Voronoi cells for spheres (like voro++)? It
would be useful not only for me, I think.
Check revno252
Not yet. But "CGAL needs 1.4sec for 100k spheres" is very good. This
is what CPU?
1.3sec in average for triangulate() with the script lines commited
earlier :-) (the other test was out-of-yade program).
This is on intel Xeon. Let me know what it gives on your laptop if you
give it a try.
No
> > reason (experimental, might change without notice etc).
> Heh, that's why I asked. :)
Oh, sorry, I overlooked the postscriptum. Never mind. There is no proper
solution currently, if you want to use multiple scene objects
You should make the default shared_ptr(), then test it, and if it
is
> tt=TriaxialTest()\ntt.generate('test.xml')\nO.load('test.xml')
>
TriaxialTest().load()
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://h
Example is in header + docstring now (docstring is hardly readable in hpp).
reason (experimental, might change without notice etc).
Heh, that's why I asked. :)
You should pass
no argument to triangulate, instead use Omega::instance().getScene() in
the function.
In typical situations, TW
> Check revno2526. Example in the header :
Can you put that to the docstring instead?
> TW.triangulate(O._sceneObj()) //compute regular Delaunay triangulation,
Just to reming you that O._sceneObj has the leading underscore for a
reason (experimental, might change without notice etc). You should pa
Not yet. But "CGAL needs 1.4sec for 100k spheres" is very good. This
is what CPU? And couldn't you give a some working script, such as
calculate the volume of Voronoi cells for spheres (like voro++)? It
would be useful not only for me, I think.
Check revno2526. Example in the header :
tt=T
02.11.2010 15:32, Bruno Chareyre:
By the way, Sergei, did you find how to use this
TesselationW->Volume(id) in Yade?
No.
Did you try, and are you still interested? I see it needs a few py
functions defined in order to do it all from python.
Not yet. But "CGAL needs 1.4sec for 100k spheres
By the way, Sergei, did you find how to use this
TesselationW->Volume(id) in Yade?
No.
Did you try, and are you still interested? I see it needs a few py
functions defined in order to do it all from python.
B.
___
Mailing list: https://launchpad
> In flow coupling, we need triangulations updated at run-time, which
> makes CPU time a major issue. I forget using Voro++ for this reason.
> For post-processing applications like this, we don't need tesselation,
> but only triangulation : https://yade-dem.org/wiki/Triangulation.
> I agree that
CGAL needs 1.4sec for 100k spheres (regular triangulation, probably less
for simple Delaunay).
In flow coupling, we need triangulations updated at run-time, which
makes CPU time a major issue. I forget using Voro++ for this reason.
For post-processing applications like this, we don't need tessela
29.10.2010 22:03, Bruno Chareyre:
By the way, Sergei, did you find how to use this
TesselationW->Volume(id) in Yade?
No.
I've been looking a little, but it needs
more time to understand how to use it. Fluid coupling needs iterations
on tetrahedra of the triangulation, and they don't seem to
Hi,
I personally use voro++. I think it is more appropriate (simple) if you only
need the cells with circumcenter-vertices (instead of
particle-center-vertices). In voro++ there is not iterator to loop over edges,
faces or something else. Instead, you need to know the internal structure.
The
By the way, Sergei, did you find how to use this
TesselationW->Volume(id) in Yade?
B.
On 29/10/10 17:18, Bruno Chareyre wrote:
Thanks for suggestion Vaclav. I've been looking a little, but it needs
more time to understand how to use it. Fluid coupling needs iterations
on tetrahedra of the tri
Thanks for suggestion Vaclav. I've been looking a little, but it needs
more time to understand how to use it. Fluid coupling needs iterations
on tetrahedra of the triangulation, and they don't seem to be
explicitely defined in Voro++.
Sergei, why "faster"? Did you compare CPU times with CGAL?
Thanks a lot V.
I'll have a look right now.
ema
On 10/29/2010 03:30 PM, Sergei D. wrote:
I stumbled accross http://math.lbl.gov/voro++/examples/radical/ (what
they call "radical" is what you call "weighted"). Perhaps it could be
useful for Ema with the periodic tringulation which CGAL does n
I stumbled accross http://math.lbl.gov/voro++/examples/radical/ (what
they call "radical" is what you call "weighted"). Perhaps it could be
useful for Ema with the periodic tringulation which CGAL does not
handle. Note that the code was produced for analyzing particle flows
(with LAMMMS).
Chee
Hie Ema and Bruno,
I stumbled accross http://math.lbl.gov/voro++/examples/radical/ (what
they call "radical" is what you call "weighted"). Perhaps it could be
useful for Ema with the periodic tringulation which CGAL does not
handle. Note that the code was produced for analyzing particle flows
(wit
20 matches
Mail list logo
