Re: [Yade-dev] [Bug 681018] Re: Crash in last revision
Hi Guys! I just had a try with the new version, and finally, it works fine for me as well. Thanks Klaus On Thu, Nov 25, 2010 at 10:15 AM, Anton Gladky 681...@bugs.launchpad.netwrote: Thanks a lot, Vaclav! All is Ok now. Anton -- Crash in last revision https://bugs.launchpad.net/bugs/681018 You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. Status in Yet Another Dynamic Engine: In Progress Bug description: The simulation starts and after couple seconds of simulation it crashes. The problem is in O.bodies.erase(i.id) Test script and backtrace are attached. ___ Mailing list: https://launchpad.net/~yade-devhttps://launchpad.net/%7Eyade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-devhttps://launchpad.net/%7Eyade-dev More help : https://help.launchpad.net/ListHelp -- Crash in last revision https://bugs.launchpad.net/bugs/681018 You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. Status in Yet Another Dynamic Engine: In Progress Bug description: The simulation starts and after couple seconds of simulation it crashes. The problem is in O.bodies.erase(i.id) Test script and backtrace are attached. ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] New Material and new contact law
Hi Guys! I have to implement a simple contact law which considers normal tensile force only but elasto-plastic behaviour (steel wire). Once the connection breaks there is no more interaction. Any idea if there is already something similar in the code? Any suggestion how to start? I was thinking to create a new material ElPlastMat. Makes it sense or not? I am still not really familiar with the code. So I appreciate any kind of help. Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Debugging
Hi gys! Can someone tell me how debugging is working? I used the debug option when compiling and the LOG-statements in the code, but I couldn't get any output when running a simulation with yade. Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Trunk is not compiling
Hi guys! I just made a checkout of the actual trunk (bzr2640) and tried to compile it. It doesn't work. To me it looks like there are some problems in respect to some includ files. I tried to fix it but once one error is solved I get a new one just related to another include. The first compiler output is attached. Thanks Klaus scons: Reading SConscript files ... @@@ Using profile default (scons.profile-default) @@@ Yade version is `bzr2640' (bzr2640), installed files will be suffixed with `-bzr2640'. All intermediary files will be in `/home/thoeni/YADE/build-bzr2640'. Mkdir(/home/thoeni/YADE/build-bzr2640) Checking whether c++ compiler g++ works...yes Finding libstdc++ library... (cached) /usr/lib/libstdc++.so.6 Checking for pthread_exit(NULL) in C library pthread... yes Checking for Python development files... ok Checking for C++ header file numpy/ndarrayobject.h... yes Checking for required python modules... (cached) all ok Checking boost libraries... all ok Checking for C++ header file boost/foreach.hpp... yes Checking for C++ header file Eigen/Core... yes Checking for C++ header file loki/NullType.h... yes Checking for glutGetModifiers() in C++ library glut... yes Checking for QGLViewer() in C++ library qglviewer-qt4... yes Checking for vtkInstantiator::New() in C++ library vtkCommon... yes Checking for gts_object_class() in C++ library gts... yes Checking for log4cxx::Logger::getLogger() in C++ library log4cxx... yes Deleting extra plugin /home/thoeni/YADE/trunk/home/thoeni/YADE/install/lib/yade-bzr2640/py/gts/_gts.so Deleting extra plugin /home/thoeni/YADE/trunk/home/thoeni/YADE/install/lib/yade-bzr2640/lib/libyade-support.so Deleting extra plugin /home/thoeni/YADE/trunk/home/thoeni/YADE/install/lib/yade-bzr2640/lib/libcore.so Deleting extra plugin /home/thoeni/YADE/trunk/home/thoeni/YADE/install/lib/yade-bzr2640/lib/libyade-opengl.so Rebuilding combined files, since the md5 has changed. scons: done reading SConscript files. scons: Building targets ... C py/3rd-party/pygts-0.3.1/cleanup.c home/thoeni/YADE/install/bin/yade-bzr2640-batch home/thoeni/YADE/install/bin/yade-bzr2640 Chmod(/home/thoeni/YADE/trunk/home/thoeni/YADE/install/bin/yade-bzr2640, 0755) Chmod(/home/thoeni/YADE/trunk/home/thoeni/YADE/install/bin/yade-bzr2640-batch, 0755) C py/3rd-party/pygts-0.3.1/face.c In file included from /usr/include/python2.6/Python.h:8, from py/3rd-party/pygts-0.3.1/pygts.h:39, from py/3rd-party/pygts-0.3.1/cleanup.c:36: /usr/include/python2.6/pyconfig.h:1031: warning: _POSIX_C_SOURCE redefined /usr/include/features.h:213: note: this is the location of the previous definition C py/3rd-party/pygts-0.3.1/edge.c In file included from /usr/include/python2.6/Python.h:8, from py/3rd-party/pygts-0.3.1/pygts.h:39, from py/3rd-party/pygts-0.3.1/face.c:28: /usr/include/python2.6/pyconfig.h:1031: warning: _POSIX_C_SOURCE redefined /usr/include/features.h:213: note: this is the location of the previous definition In file included from /usr/include/python2.6/Python.h:8, from py/3rd-party/pygts-0.3.1/pygts.h:39, from py/3rd-party/pygts-0.3.1/edge.c:28: /usr/include/python2.6/pyconfig.h:1031: warning: _POSIX_C_SOURCE redefined /usr/include/features.h:213: note: this is the location of the previous definition C py/3rd-party/pygts-0.3.1/object.c In file included from /usr/include/python2.6/Python.h:8, from py/3rd-party/pygts-0.3.1/pygts.h:39, from py/3rd-party/pygts-0.3.1/object.c:28: /usr/include/python2.6/pyconfig.h:1031: warning: _POSIX_C_SOURCE redefined /usr/include/features.h:213: note: this is the location of the previous definition C py/3rd-party/pygts-0.3.1/point.c C py/3rd-party/pygts-0.3.1/pygts.c In file included from /usr/include/python2.6/Python.h:8, from py/3rd-party/pygts-0.3.1/pygts.h:39, from py/3rd-party/pygts-0.3.1/point.c:28: /usr/include/python2.6/pyconfig.h:1031: warning: _POSIX_C_SOURCE redefined /usr/include/features.h:213: note: this is the location of the previous definition In file included from /usr/include/python2.6/Python.h:8, from py/3rd-party/pygts-0.3.1/pygts.h:39, from py/3rd-party/pygts-0.3.1/pygts.c:28: /usr/include/python2.6/pyconfig.h:1031: warning: _POSIX_C_SOURCE redefined /usr/include/features.h:213: note: this is the location of the previous definition C py/3rd-party/pygts-0.3.1/segment.c In file included from /usr/include/python2.6/Python.h:8, from py/3rd-party/pygts-0.3.1/pygts.h:39, from py/3rd-party/pygts-0.3.1/segment.c:28: /usr/include/python2.6/pyconfig.h:1031: warning: _POSIX_C_SOURCE redefined /usr/include/features.h:213: note: this is the location of the previous definition C py/3rd-party/pygts-0.3.1/surface.c C py/3rd-party/pygts-0.3.1/triangle.c In file included from /usr/include/python2.6/Python.h:8,
[Yade-dev] Last changes
Hi guys! A lot of changes have been done in the last few weeks. I just tried to run some scripts and I ended up with some troubles. Somehow I fixed my scripts for the WireMatPM but I couldn't really understand why I needed this changes. Someone can explain it to me please? Some other scripts I tried to run and give problems are: scripts/test/mindlin.py scripts/normalInelasticity-test.py Some problems seem to be related to matplotlib, e.g. in my scripts the default values for plot.plot() have not been accepted and the legend in the live plot has additional names as shown in the attachments (collection0...n). However, I couldn't find out why for my tests Renderer().intrAllWire=True is not showing the interaction any more. Any idea? Thanks Klaus attachment: image.png___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Packings for WireMat
Hi Anton! Indeed, it is a very specific packing but I am sure it might be useful. Regarding description and example. The documentation is updated automatically as well for the python files, isn't it? Or do I have do add something in the documentation files? The code is well documented. Thanks Klaus On Tue, 25 Jan 2011 11:43:16 pm Anton Gladky wrote: Hi, Klaus, it seems like it is a very specific packing way. But if you think, that it can be useful for somebody, you can add it to the trunk with corresponding description and example. Anton On Mon, Jan 24, 2011 at 12:39 AM, Klaus Thoeni klaus.tho...@gmail.com wrote: Hi guys! I wanted to ask if I can add my non-standard packings for my rockfall net (WireMatPM) to py/pack/pack.py. One of the packings is shown in the attachment. The packing works without predicate and particles are generated on a plane (x-y) only. The definition looks something like: def hexaNet( cornerCoord, xLenght, yLenght, radius, mos, isRegular, startAtCorner, isSymmetric, **kw ): What do you think, can I add it or should I keep it in my script? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Contact between two different materials
Hi Guys! I try to implement an interaction between two different materials, e.g. between FrictMat and my WireMat. My first guess would be to implement (in WirePM.cpp): 1. Ip2_WireMat_FrictMat_FrictPhys 2. Law2_ScGeam_FrictPhys_WirePM Any comments or suggestions? I saw that Chiara posted a similar questions last year but I couldn't find any implementation for that. So did anyone already implement something similar? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Contact between two different materials
Hi! Tried to inherit WireMat from FrictMat and using Ip2_FrictMat_FrictMat_FrictPhys() Law2_ScGeom_FrictPhys_CundallStrack() but got this: terminate called after throwing an instance of 'std::runtime_error' what(): Undefined or ambiguous IPhys dispatch for types FrictMat and WireMat. Aborted Any suggestions where the problem could be? Thanks Klaus P.S.: Bruno, your script is not up do date! On Mon, 28 Feb 2011 06:30:12 pm Bruno Chareyre wrote: Hi Klaus, It sounds correct. I think you are the first to do that. I don't know if it will apply in your case, but note that it is possible to make different materials interact without a Ip2_M1_M2_Phys functor, as long as M2 inherits from M1 (or vice-versa). See for instance: https://yade-dem.org/wiki/Screenshots_and_videos#Representing_beams_and_wir es_with_connected_cylinder - spheres and boxes have FrictMat - cylinders have CohFrictMat Cylinders interact with the other shapes even though there is no FrictMat_CohFrictMat functor. Since CohFrictMat inherits from FrictMat, sphere-cylinder and box-cylinder interactions will get FrictPhys from Ip2_FrictMat_FrictMat_FrictPhys, and only cylinder-cylinder interactions will be cohesive. You could use the same strategy by making WireMat inherit from FrictPhys (which would be logical if the WireMat interacts frictionaly with spheres), if you think it is more convenient. For the contact law, same remark: you need an additional contact law _only if_ it will implement a new behaviour, else you can use one of the existing laws (e.g. Law2_ScGeom_FrictPhys_CundallStrack is used for cylinder-sphere interactions). Cheers. Bruno On 28/02/11 06:34, Klaus Thoeni wrote: Hi Guys! I try to implement an interaction between two different materials, e.g. between FrictMat and my WireMat. My first guess would be to implement (in WirePM.cpp): 1. Ip2_WireMat_FrictMat_FrictPhys 2. Law2_ScGeam_FrictPhys_WirePM Any comments or suggestions? I saw that Chiara posted a similar questions last year but I couldn't find any implementation for that. So did anyone already implement something similar? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Contact between two different materials
Indeed, my fault. I forgot to change some of the ElastMat to FrictMat in the declaration. Strange that there was no error during compiling. It's working fine now. Thanks a lot Klaus On Tue, 1 Mar 2011 11:55:49 pm Bruno Chareyre wrote: Tried to inherit WireMat from FrictMat and using Ip2_FrictMat_FrictMat_FrictPhys() Law2_ScGeom_FrictPhys_CundallStrack() but got this: terminate called after throwing an instance of 'std::runtime_error' what(): Undefined or ambiguous IPhys dispatch for types FrictMat and WireMat. Aborted Any suggestions where the problem could be? Hard to guess just like that. Double-check that all types declarations are correct in macros like YADE_BASE_... and FUNCTOR2D, make sure that there is not a Frict_Wire and a Frict_Frict functor in the same simulation (else it would be ambiguous), compile with debug symbols and set the highest LOG level for dispatcher to get more details on the failure. Others will have better ideas perhaps. Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] farewell
Hi Vaclav! I am sure we will miss you! Anyway, good luck with your new plans. Regarding your new plans, please keep us updated since coupling is a very interesting topic. I am already looking forward to see some nice animations from your new developments on youtube ;-) Cheers Klaus On Fri, 18 Mar 2011 08:09:40 am Václav Šmilauer wrote: I hope, yade will survive without your contribution. http://www.youtube.com/watch?v=XM1fDkC4c0Q Are we having mailing-list funeral?! Cheer up, it is just a piece of code! Also it would be interesting to know about your new project. I will let you know on the list, but (if ever) it will not be before many months will have passed. There is no sense announcing project which is not even clearly defined; you can search freshmeat / sourceforge, plenty open-source projects have just written their title and description, never commited any code, only to have their homepage become their epitaph of sorts, after a few years. v PS. http://www.youtube.com/watch?v=__OSyznVDOY ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Branch ~yade-dev/yade/trunk] Rev 2819: 1. correct affiliation in doc/sphinx/conf.py
Done! On Mon, 18 Apr 2011 04:15:25 pm Bruno Chareyre wrote: 3. add value which indicates how far interactions are from normal failing (currently just used in WirePM) modified: pkg/common/NormShearPhys.hpp Sorry Klaus, could you revert this please? Have a look here: https://yade-dem.org/doc/yade.wrapper.html#iphys Basically, you added a parameter to all interactions in Yade, which is useless for all but one class. If you need this additional data, better add it to the class that needs it (WirePhys). Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] How to change the macros
Hoi Anna, as already pointed out by Bruno and Anton it makes no sense to change Serializable.hpp. If you want to add more parameters to to WireMat you have to define it in WirePM.hpp. However, in order to use this new parameters you would have to change the code in WirePM.cpp as well. Anyway, the actual code uses two different stress-strain-curves where the one for the double-twist is computed from the single wire curve by using the parameters lambda_eps and lambda_k (see Bertrand, some assumptions are made and the single wire curve is somehow scaled to get the one for the double twist). So if you know your stress-strain-curve for the double twist you just have to find out which parameters give you the expected behaviour. HTH Klaus On Tue, 26 Apr 2011 11:20:14 pm Anna Effeindzourou wrote: Hi, I try to change the macros in Serializable.hpp in order to have more parameters when I define the wireMat (I have join the code) I want to have possibility to enter two curves but it doesn't work. I have this error with the code join with this mail: home/anna/yade/lib/serialization/Serializable.hpp: In member function 'PyObject* boost::python::objects::caller_py_function_implCaller::operator()(PyObjec t*, PyObject*) [with Caller = boost::python::detail::callerPyObject* (*)(Serializable, const Serializable), boost::python::default_call_policies, boost::mpl::vector3PyObject*, Serializable, const Serializable ]': /home/anna/yade/lib/serialization/Serializable.hpp:264: warning: dereferencing pointer 'p.2661' does break strict-aliasing rules /usr/include/boost/python/detail/destroy.hpp:90: note: initialized from here /home/anna/build-trunk/include/yade/lib/factory/Factorable.hpp:63: warning: dereferencing pointer 'this.685' does break strict-aliasing rules /home/anna/yade/lib/serialization/Serializable.hpp:264: note: initialized from here /home/anna/yade/lib/serialization/Serializable.hpp:264: warning: dereferencing pointer 'p.2661' does break strict-aliasing rules /usr/include/boost/python/detail/destroy.hpp:90: note: initialized from here /home/anna/build-trunk/include/yade/lib/factory/Factorable.hpp:63: warning: dereferencing pointer 'this.685' does break strict-aliasing rules /home/anna/yade/lib/serialization/Serializable.hpp:264: note: initialized from here scons: *** [/home/anna/build-trunk/lib/yade-support.os] Error 1 scons: *** [/home/anna/build-trunk/core/core.os] Error 1 scons: building terminated because of errors. What can I do to make it work? Thanks in advance, Anna -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized collider needs testing
Hi Bruno, I checked out your branch lp:~bruno-chareyre/yade/collide (without 2 at the end as indicated in the bzr co part of your first posting) when I tested it. I just saw now that there is as well a branch lp:~bruno-chareyre/yade/collide2. Probably that's the one to test. This explains why it was working. I will do the tests with this branch now. So guys if you want to test Bruno's new implementation make sure you check out the right branch: bzr checkout lp:~bruno-chareyre/yade/collide2 Cheers, Klaus On Tue, 27 Sep 2011 10:43:28 pm Bruno Chareyre wrote: There was indeed a bug with clumps (fixed), but the thing I don't understand is the branch did not contain the changes. Bazaar branches are not quite user-friendly for commits/updates... Klaus, you probably didn't try the good code (but then how did you spot the bug? I'm lost...). Could you send me a copy of the core/bound.hpp you downloaded, just to be sure? Bruno On 26/09/11 10:37, Bruno Chareyre wrote: (moving to yade-dev) No guess yet. Thanks for notifying. Which scripts gives the segfault? B On 26/09/11 07:43, Klaus Thoeni wrote: Hi Bruno, I tested your implementation with my examples (dynamic problem with about 1 particles) and the computational time in InsertionSortCollider slightly improved as expected. However, when running your branch with examples with clumps gives a Segmentation Fault. Any guess? Klaus On Tue, 20 Sep 2011 07:29:02 AM Bruno Chareyre wrote: Hi all, I worked on some optimizations of contact detection recently and I would like to get feedback from you to detect possible bugs and confirm the speedup for different applications. If everything is ok, the changes can be part of the next release after some code cleanup and documentation. If you have a chance, could you please download and compile the branch lp:~bruno-chareyre/yade/collide2 (bzr checkout lp:~bruno-chareyre/yade/collide, cd yade, scons, as usual) and try this with your own problems? I would be gratefull if you could report differences in terms of computation speed. I don't expect big improvements for small quasistatic problems. The speedup is more likely to happen on large and/or dynamic problems, where it should range between x2 and x3, or even more in multithread. Some results are reported here: https://yade-dem.org/wiki/Colliders_performace#Improved_InsertionSort Thanks. Bruno -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized collider needs testing
Hi guys, don't forget to enable feature cgal before compiling ;-) I checked my test with the implementation in branch lp:~bruno- chareyre/yade/collide2. Computational speed improves compared to trunk version. Very good! And clumps are working as well. Good job Bruno! Cheers Klaus On Tue, 27 Sep 2011 10:43:28 pm Bruno Chareyre wrote: There was indeed a bug with clumps (fixed), but the thing I don't understand is the branch did not contain the changes. Bazaar branches are not quite user-friendly for commits/updates... Klaus, you probably didn't try the good code (but then how did you spot the bug? I'm lost...). Could you send me a copy of the core/bound.hpp you downloaded, just to be sure? Bruno On 26/09/11 10:37, Bruno Chareyre wrote: (moving to yade-dev) No guess yet. Thanks for notifying. Which scripts gives the segfault? B On 26/09/11 07:43, Klaus Thoeni wrote: Hi Bruno, I tested your implementation with my examples (dynamic problem with about 1 particles) and the computational time in InsertionSortCollider slightly improved as expected. However, when running your branch with examples with clumps gives a Segmentation Fault. Any guess? Klaus On Tue, 20 Sep 2011 07:29:02 AM Bruno Chareyre wrote: Hi all, I worked on some optimizations of contact detection recently and I would like to get feedback from you to detect possible bugs and confirm the speedup for different applications. If everything is ok, the changes can be part of the next release after some code cleanup and documentation. If you have a chance, could you please download and compile the branch lp:~bruno-chareyre/yade/collide2 (bzr checkout lp:~bruno-chareyre/yade/collide, cd yade, scons, as usual) and try this with your own problems? I would be gratefull if you could report differences in terms of computation speed. I don't expect big improvements for small quasistatic problems. The speedup is more likely to happen on large and/or dynamic problems, where it should range between x2 and x3, or even more in multithread. Some results are reported here: https://yade-dem.org/wiki/Colliders_performace#Improved_InsertionSort Thanks. Bruno -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized collider needs testing
Yes, it is listed. You have just to to change Branches with status: Any status. That's how I found out that there are 2 collide branches. Klaus On Wed, 28 Sep 2011 06:01:29 pm Bruno Chareyre wrote: Ok thanks. It explains. lp:~bruno-chareyre/yade/collide2 contains further improvements (and code cleaning) as compared to lp:~bruno-chareyre/yade/collide, which was already faster than trunk. But before yesterday, collide2 was simply trunk. collide without the 2 should not exist actually, it's not listed here for instance: https://code.launchpad.net/yade I'm surprised that you could download it. Bruno On 28/09/11 04:49, Klaus Thoeni wrote: Hi Bruno, I checked out your branch lp:~bruno-chareyre/yade/collide (without 2 at the end as indicated in the bzr co part of your first posting) when I tested it. I just saw now that there is as well a branch lp:~bruno-chareyre/yade/collide2. Probably that's the one to test. This explains why it was working. I will do the tests with this branch now. So guys if you want to test Bruno's new implementation make sure you check out the right branch: bzr checkout lp:~bruno-chareyre/yade/collide2 Cheers, Klaus On Tue, 27 Sep 2011 10:43:28 pm Bruno Chareyre wrote: There was indeed a bug with clumps (fixed), but the thing I don't understand is the branch did not contain the changes. Bazaar branches are not quite user-friendly for commits/updates... Klaus, you probably didn't try the good code (but then how did you spot the bug? I'm lost...). Could you send me a copy of the core/bound.hpp you downloaded, just to be sure? Bruno On 26/09/11 10:37, Bruno Chareyre wrote: (moving to yade-dev) No guess yet. Thanks for notifying. Which scripts gives the segfault? B On 26/09/11 07:43, Klaus Thoeni wrote: Hi Bruno, I tested your implementation with my examples (dynamic problem with about 1 particles) and the computational time in InsertionSortCollider slightly improved as expected. However, when running your branch with examples with clumps gives a Segmentation Fault. Any guess? Klaus On Tue, 20 Sep 2011 07:29:02 AM Bruno Chareyre wrote: Hi all, I worked on some optimizations of contact detection recently and I would like to get feedback from you to detect possible bugs and confirm the speedup for different applications. If everything is ok, the changes can be part of the next release after some code cleanup and documentation. If you have a chance, could you please download and compile the branch lp:~bruno-chareyre/yade/collide2 (bzr checkout lp:~bruno-chareyre/yade/collide, cd yade, scons, as usual) and try this with your own problems? I would be gratefull if you could report differences in terms of computation speed. I don't expect big improvements for small quasistatic problems. The speedup is more likely to happen on large and/or dynamic problems, where it should range between x2 and x3, or even more in multithread. Some results are reported here: https://yade-dem.org/wiki/Colliders_performace#Improved_InsertionSort Thanks. Bruno -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized collider needs testing
...e no, compilation is breaking now, independent if you activate cgal or not. First, yade was giving an error on runtime if I didn't activate cgal feature. Klaus On Wed, 28 Sep 2011 06:55:50 pm Bruno Chareyre wrote: Does it break compilation without cgal? Oh dear... Then it's another bug Fixed. ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5118 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Strange behaviour of function unbalancedForce
Hi guys, I just wanted to use the function unbalancedForce in one of my scripts. And look what is happening: running the same simulation several times after each other gives different results for the unbalancedForce. Well either some values which seem all right or just zero. The script I used is: examples/WireMatPM/wirecontacttest.py Even using different computers and different versions of yade gives this problem. However, it doesn't happen all the time. It seems like you have to try several times to get the wrog value (which is zero) for unbalancedForce and if I use Bruno's collide2 branch it seems to work all the time. So I don't know if it is a problem with my script or a problem of the current trunk version. Can anyone reproduce this problem? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Strange behaviour of function unbalancedForce
Hi Anton, I tired it already (I know this issue), still the same behaviour. And now actually I got zero for Bruno's branch as well. Very strange :-( Not sure what the problem is. Would be great if someone could try if he/she gets the same behaviour. Thanks, Klaus On Thu, 6 Oct 2011 04:30:53 PM Anton Gladky wrote: Hi Klaus, try to start your script with -j1 option. There are sometimes some issues with numerical error in multi-thread mode. Anton On Thu, Oct 6, 2011 at 6:40 AM, Klaus Thoeni klaus.tho...@gmail.com wrote: Hi guys, I just wanted to use the function unbalancedForce in one of my scripts. And look what is happening: running the same simulation several times after each other gives different results for the unbalancedForce. Well either some values which seem all right or just zero. The script I used is: examples/WireMatPM/wirecontacttest.py Even using different computers and different versions of yade gives this problem. However, it doesn't happen all the time. It seems like you have to try several times to get the wrog value (which is zero) for unbalancedForce and if I use Bruno's collide2 branch it seems to work all the time. So I don't know if it is a problem with my script or a problem of the current trunk version. Can anyone reproduce this problem? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Strange behaviour of function unbalancedForce
Hi, yes, if you pause the simulation unbalancedForce() is still exactly 0. Regarding the results for displacements: - if I run the same file with -j1 I will get exactly the same deformation, however the the unbalancedForce is not exactly the same - if I compare the displacements of a case where I used multi-threading the displacements are exactly the same for a certain amount of iterations then the slightly differ (even if unbalancedForce is 0 from beginning) I am still trying to find out what's going on. Any hints are welcome! Thanks, Klaus On Fri, Oct 7, 2011 at 9:35 PM, Bruno Chareyre bruno.chare...@hmg.inpg.frwrote: I can't imagine any explanation yet. It is strange. I wonder if the unbalanced force will also be exactly 0 if you pause the simulation and type unbalancedForce() in the terminal. Are you sure that the results in terms of positions and deformation of the net are always the same? else it could mean that there is another problem that the unbalanced force is only reflecting. Bruno On 07/10/11 07:08, Klaus Thoeni wrote: Hi guys, yes, you have to try it several times in order to reproduce the strange behaviour. However, I found out a bit more. Actually it might be a problem with multi- threading. Maybe someone can try to reproduce the behaviour. The following link provides a slightly modified version my script and a bash script which allows for several executions for -j1 and -j2 (before running the script make sure it is executable 'chmod +x runscript'). In addition I included as well my results. http://bit.ly/rtN0w3 Something very strange is that my desktop has the same problem even with -j1 (eaven cpu usage is more than 100% and I have no idea why) whereas my notebook gives the right results in that case (cpu usage is max 100%) just have a look at the graphs. It would be good to find out if this problem effects just me or if it is a general problem in YADE. Any hints are welcome and I really appreciate your help! Thanks Klaus On Thu, 6 Oct 2011 07:58:24 PM Bruno Chareyre wrote: I tried the script and didn't find the problem. It needs more runs maybe. But first, could you explain how you use the function (in a periodic engine/ live typing/a command in the script)? It would help understanding what happens. Bruno On 06/10/11 07:53, Klaus Thoeni wrote: Hi Anton, I tired it already (I know this issue), still the same behaviour. And now actually I got zero for Bruno's branch as well. Very strange :-( Not sure what the problem is. Would be great if someone could try if he/she gets the same behaviour. Thanks, Klaus On Thu, 6 Oct 2011 04:30:53 PM Anton Gladky wrote: Hi Klaus, try to start your script with -j1 option. There are sometimes some issues with numerical error in multi-thread mode. Anton On Thu, Oct 6, 2011 at 6:40 AM, Klaus Thoeni klaus.tho...@gmail.com wrote: Hi guys, I just wanted to use the function unbalancedForce in one of my scripts. And look what is happening: running the same simulation several times after each other gives different results for the unbalancedForce. Well either some values which seem all right or just zero. The script I used is: examples/WireMatPM/wirecontacttest.py Even using different computers and different versions of yade gives this problem. However, it doesn't happen all the time. It seems like you have to try several times to get the wrog value (which is zero) for unbalancedForce and if I use Bruno's collide2 branch it seems to work all the time. So I don't know if it is a problem with my script or a problem of the current trunk version. Can anyone reproduce this problem? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP 11, rue des Mathématiques BP 46 38402 St Martin d'Hères, 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 : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Strange behaviour of function unbalancedForce
Hi Bruno, I just had a look at the code and NormShearPhys is used in many other places as well. This means that it is always assumend that there is a normal and a shear force. So probably I should derive WirePhys from NormSherPhys and set ks and Fs equal to zero. What do you think? Klaus On Mon, 10 Oct 2011 11:51:40 PM Bruno Chareyre wrote: Hi, If you can get 0 after pausing, then it's a good starting point for debugging. In release build, you may try and check if there are forces on the bodies. In debug build (does it give 0 too?) you could set a breakpoint at Shop.cpp:162 and see what happens line by line, surely the best way. Bruno On 10/10/11 14:16, Klaus Thoeni wrote: Hi, yes, if you pause the simulation unbalancedForce() is still exactly 0. Regarding the results for displacements: - if I run the same file with -j1 I will get exactly the same deformation, however the the unbalancedForce is not exactly the same - if I compare the displacements of a case where I used multi-threading the displacements are exactly the same for a certain amount of iterations then the slightly differ (even if unbalancedForce is 0 from beginning) I am still trying to find out what's going on. Any hints are welcome! Thanks, Klaus On Fri, Oct 7, 2011 at 9:35 PM, Bruno Chareyre bruno.chare...@hmg.inpg.fr mailto:bruno.chare...@hmg.inpg.fr wrote: I can't imagine any explanation yet. It is strange. I wonder if the unbalanced force will also be exactly 0 if you pause the simulation and type unbalancedForce() in the terminal. Are you sure that the results in terms of positions and deformation of the net are always the same? else it could mean that there is another problem that the unbalanced force is only reflecting. Bruno On 07/10/11 07:08, Klaus Thoeni wrote: Hi guys, yes, you have to try it several times in order to reproduce the strange behaviour. However, I found out a bit more. Actually it might be a problem with multi- threading. Maybe someone can try to reproduce the behaviour. The following link provides a slightly modified version my script and a bash script which allows for several executions for -j1 and -j2 (before running the script make sure it is executable 'chmod +x runscript'). In addition I included as well my results. http://bit.ly/rtN0w3 Something very strange is that my desktop has the same problem even with -j1 (eaven cpu usage is more than 100% and I have no idea why) whereas my notebook gives the right results in that case (cpu usage is max 100%) just have a look at the graphs. It would be good to find out if this problem effects just me or if it is a general problem in YADE. Any hints are welcome and I really appreciate your help! Thanks Klaus On Thu, 6 Oct 2011 07:58:24 PM Bruno Chareyre wrote: I tried the script and didn't find the problem. It needs more runs maybe. But first, could you explain how you use the function (in a periodic engine/ live typing/a command in the script)? It would help understanding what happens. Bruno On 06/10/11 07:53, Klaus Thoeni wrote: Hi Anton, I tired it already (I know this issue), still the same behaviour. And now actually I got zero for Bruno's branch as well. Very strange :-( Not sure what the problem is. Would be great if someone could try if he/she gets the same behaviour. Thanks, Klaus On Thu, 6 Oct 2011 04:30:53 PM Anton Gladky wrote: Hi Klaus, try to start your script with -j1 option. There are sometimes some issues with numerical error in multi-thread mode. Anton On Thu, Oct 6, 2011 at 6:40 AM, Klaus Thoeni klaus.tho...@gmail.com mailto:klaus.tho...@gmail.com wrote: Hi guys, I just wanted to use the function unbalancedForce in one of my scripts. And look what is happening: running the same simulation several times after each other gives different results for the unbalancedForce. Well either some values which seem all right or just zero. The script I used is: examples/WireMatPM/wirecontacttest.py Even using different computers and different versions of yade gives
Re: [Yade-dev] Strange behaviour of function unbalancedForce
Hi Bruno, I derived my WireMat from NormShearPhys and indeed it is working fine now. I think for now it's the best solution. Let me know if you are happy with this solution. If in the future we have more cases with normal forces only it might be better to introduce the boolean you mentioned. But we would have to check it in several lines inthe code. Regarding the results I got previously. All results where wrong, although they where the same if I used one threat. Well, in debug mode the simulation was not running because of the assert. Thanks, Klaus On Wed, 12 Oct 2011 12:06:39 AM Bruno Chareyre wrote: Yes, deriving from NormShear would do the trick. It is suboptimal in terms of memory usage but the impact will be small. There could be other ways, like passing an optional bool hasShear to the unbalancedForce function, but it would solve only one specific problem and if normShearPhys is used everywhere you will indeed hit the same problem again with other functions. Something I still don't get is why it works _sometimes_, and why your interactions don't simply give a crash on the typecasting: shared_ptrNormShearPhys nsi=YADE_PTR_CASTNormShearPhys(I-phys); Any idea? Bruno p.s. Please, don't send mails to me+yade-dev (it makes duplicates in my mbox and it disables the reply-to-list feature of thunderbird), yade-dev alone will be enough. On 11/10/11 09:50, Klaus Thoeni wrote: Hi Bruno, I just had a look at the code and NormShearPhys is used in many other places as well. This means that it is always assumend that there is a normal and a shear force. So probably I should derive WirePhys from NormSherPhys and set ks and Fs equal to zero. What do you think? Klaus On Mon, 10 Oct 2011 11:51:40 PM Bruno Chareyre wrote: Hi, If you can get 0 after pausing, then it's a good starting point for debugging. In release build, you may try and check if there are forces on the bodies. In debug build (does it give 0 too?) you could set a breakpoint at Shop.cpp:162 and see what happens line by line, surely the best way. Bruno On 10/10/11 14:16, Klaus Thoeni wrote: Hi, yes, if you pause the simulation unbalancedForce() is still exactly 0. Regarding the results for displacements: - if I run the same file with -j1 I will get exactly the same deformation, however the the unbalancedForce is not exactly the same - if I compare the displacements of a case where I used multi-threading the displacements are exactly the same for a certain amount of iterations then the slightly differ (even if unbalancedForce is 0 from beginning) I am still trying to find out what's going on. Any hints are welcome! Thanks, Klaus On Fri, Oct 7, 2011 at 9:35 PM, Bruno Chareyre bruno.chare...@hmg.inpg.fr mailto:bruno.chare...@hmg.inpg.fr wrote: I can't imagine any explanation yet. It is strange. I wonder if the unbalanced force will also be exactly 0 if you pause the simulation and type unbalancedForce() in the terminal. Are you sure that the results in terms of positions and deformation of the net are always the same? else it could mean that there is another problem that the unbalanced force is only reflecting. Bruno On 07/10/11 07:08, Klaus Thoeni wrote: Hi guys, yes, you have to try it several times in order to reproduce the strange behaviour. However, I found out a bit more. Actually it might be a problem with multi- threading. Maybe someone can try to reproduce the behaviour. The following link provides a slightly modified version my script and a bash script which allows for several executions for -j1 and -j2 (before running the script make sure it is executable 'chmod +x runscript'). In addition I included as well my results. http://bit.ly/rtN0w3 Something very strange is that my desktop has the same problem even with -j1 (eaven cpu usage is more than 100% and I have no idea why) whereas my notebook gives the right results in that case (cpu usage is max 100%) just have a look at the graphs. It would be good to find out if this problem effects just me or if it is a general problem in YADE. Any hints are welcome and I really appreciate your help! Thanks Klaus On Thu, 6 Oct 2011 07:58:24 PM Bruno Chareyre wrote: I tried the script and didn't find the problem. It needs more runs maybe. But first, could you explain how you use the function (in a periodic engine/ live typing/a command in the script)? It would help
[Yade-dev] [Bug 850864] Re: strange facet-sphere behaviour
Hi guys, have a look at the attached script. There is for sure a problem when spheres collide with facets. However, the behaviour is very strange and the problem does not appear always. If you have a look at the plot of the script you will see that the problem appears at the fourth collision. Actually I tried to play as well with the damping coefficient and the time step and for some configurations there is no problem (e.g. use dc=0.1). In addition you can change the parameters in the script and you can see that the behaviour is very strange if the sphere collides with corners as well (e.g. use b=0, change z...). Well, this is very strange, any comments? And regarding this bug, I think we should change the priority and fix it is asap. Cheers Klaus ** Attachment added: Example witch shows strange behaviour https://bugs.launchpad.net/yade/+bug/850864/+attachment/2622507/+files/freefall.py -- You received this bug notification because you are a member of Yade developers, which is the registrant for Yade. https://bugs.launchpad.net/bugs/850864 Title: strange facet-sphere behaviour Status in Yet Another Dynamic Engine: Confirmed Bug description: See https://answers.launchpad.net/yade/+question/171223 Spheres that are exactly on an edge between facets behave strangely. Maybe related to other (closed, but never solved) bugs in sphere- facet. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/850864/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : GenericSpheresContact
Everyone on holidays already? Well I am still wondering why for the calculation of the stiffness of a sphere and a facet the radius of the facet is assumed to be twice the radius of the sphere. This is basically the value comming from GenericSpheresContact. In my opinion it doesn't make sense. The facet can be seen as a sphere with radius infinity. So if we take the harmonic average (as it is done in Ip2_FrictMat_FrictMat_FrictPhys ) considering e.g. rb-infinity the stiffnesses become kn = 2*Ea*ra and ks = 2*Ea*ra*Va. You agree? If so I could commit the changed code. Please let me know. On Sun, 11 Dec 2011 06:38:35 PM Klaus Thoeni wrote: Hi Guys, what value for refR does the GenericSpheresContact return for a facet? By introducing TRVAR2( Ra, Rb ) e.g. in Ip2_FrictMat_FrictMat_FrictPhys::go it seems if a sphere is intersecting with a facet the refR value for the facet is just 2*refR of the sphere. Is this true? And when yes, what's the reason? It's fundamental for kn and ks, isn't it? Thanks, Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : GenericSpheresContact
Hi all, thanks for the active discussion. So I guess we just leave it as it is and use 2 for boxes and facets if this is the usual assumption. No problem. And introducing r-infinity ignores the material properties of the facet, so I guess my suggestion was not the best one however mathematically correct ;-) Thanks again! Klaus On Tue, 13 Dec 2011 10:10:08 PM Bruno Chareyre wrote: I have no explanation for the 2*refR other than that: - there was 2*refR in box-sphere interactions a while ago (I don't know why), - facet-sphere interactions inherited this 2* from box-sphere interactions (my assumption). The thing is I changed that in box-sphere, and now refR of a box is the radius of the sphere. I can at least invoke symmetry to justify this. Infinite radius could be justified too, the problem is it would give contacts twice stiffer than the contacts between spheres, hence smaller timestep, without clear advantage. Bruno On 13/12/11 11:35, Klaus Thoeni wrote: Everyone on holidays already? Well I am still wondering why for the calculation of the stiffness of a sphere and a facet the radius of the facet is assumed to be twice the radius of the sphere. This is basically the value comming from GenericSpheresContact. In my opinion it doesn't make sense. The facet can be seen as a sphere with radius infinity. So if we take the harmonic average (as it is done in Ip2_FrictMat_FrictMat_FrictPhys ) considering e.g. rb-infinity the stiffnesses become kn = 2*Ea*ra and ks = 2*Ea*ra*Va. You agree? If so I could commit the changed code. Please let me know. On Sun, 11 Dec 2011 06:38:35 PM Klaus Thoeni wrote: Hi Guys, what value for refR does the GenericSpheresContact return for a facet? By introducing TRVAR2( Ra, Rb ) e.g. in Ip2_FrictMat_FrictMat_FrictPhys::go it seems if a sphere is intersecting with a facet the refR value for the facet is just 2*refR of the sphere. Is this true? And when yes, what's the reason? It's fundamental for kn and ks, isn't it? Thanks, Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : GenericSpheresContact
Well if it is 1 for boxes now I don't see any reason why it should be 2 for facets. Or is there a reason? Any other opinions? On Tue, 13 Dec 2011 10:46:31 PM Bruno Chareyre wrote: thanks for the active discussion. So I guess we just leave it as it is and use 2 for boxes and facets if this is the usual assumption. It is 1 for boxes now (and good like this). I didn't know 2 was usual. I would make it 1 for facet as well, but since I'm not using facets a lot, I can't decide for others. Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] : Avoid new contact detection between group of particle
Hi guys, I have a tricky question. How can I avoid new contact detection between a group of particles? For my WireMP a first create particles which represent the net. Second, I create a link between particle since particle interact remotely (there is no physical contact between these particles). However, once the link is created I want to avoid new contact detection between those particles. I still need contact detection between the net and some other particles (e.g. rock block). Any idea how to implement this? I think it must be done somewhere in the collider, or not? Thanks, Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Avoid new contact detection between group of particle
Hi Anton, thanks for your suggestion. Actually I had already a look at the groupMask option. It works fine if you have groups of particle which should interact or not, as you explain in your example. However, in my case I have three groups of particle and I want avoid contact detection between the particles of one group, the mesh. So basically I want avoid new contact detection of particles belonging to one group, or better contact between WireMat particles. I think one option could be to put all particles of this group on different groupMasks. But I have 1000s of particles in this group. Any other ideas? Thanks, Klaus On Wed, 11 Jan 2012 05:47:30 PM Anton Gladky wrote: Hi Klaus, one of possible solutions is to use groupMask', which is bitmask. For example, you have 3 groups of particles. 1 and 2, 2 and 3 should interact, otherwise 1 and 3 should not. In this case bitmask can be so written: 16 8 4 2 1 1) 1 0 0 1 0= 17 2) 0 1 0 1 1= 11 3) 0 0 1 0 1= 5 When interaction is detected, the collider (I guess) uses bitwise AND-operation for bitmasks of 2 interacting particles. And if the sum is more than 0, then interaction is created, otherwise not. So, if you see an example, the group 1 and 2, 2 and 3 will give the sum 1 and interaction will be created, 1 and 3 gives 0, so particles will not interact. Hope that helps. Anton On Wed, Jan 11, 2012 at 6:45 AM, Klaus Thoeni klaus.tho...@gmail.com wrote: Hi guys, I have a tricky question. How can I avoid new contact detection between a group of particles? For my WireMP a first create particles which represent the net. Second, I create a link between particle since particle interact remotely (there is no physical contact between these particles). However, once the link is created I want to avoid new contact detection between those particles. I still need contact detection between the net and some other particles (e.g. rock block). Any idea how to implement this? I think it must be done somewhere in the collider, or not? Thanks, Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Avoid new contact detection between group of particle
Hi Bruno, it is purely for speed up! The model already has the functionality in the IP2 functor, so creation of new interaction is omitted. However, I want to avoid new contact detection since I am running examples with huge meshes (20 particles), and this I guess is Collider related. And regarding the groupMask, If the limitation is 32 or 64 bodies this is not an option in my case. Anyone who can confirm this? I think the thematic is similar to a clump. A clump of particle is a group clumped together and contact detection in between the particle of this group is never done. How does the collider handle this? Something else I had in mined, the collider could check the material of two bodies and if it is of type WireMat then do nothing. What do you think? Thanks, Klaus On Thu, 12 Jan 2012 06:32:24 AM Bruno Chareyre wrote: Klaus, do you ask that for speedup or is it really a functionality problem? In the later case, you could use the same idea as for setCohesionNow (https://www.yade-dem.org/doc/yade.wrapper.html?highlight=setcohesionnow#ya de.wrapper.Ip2_CohFrictMat_CohFrictMat_CohFrictPhys.setCohesionNow). The difference is that the CohFrict functor keeps assigning other parameters (e.g. stiffness) when the flag is false. In your case you could just return. It would still waste a bit of time to create useless interaction geometries. Probably not a significant loss, but it would be better if the mask logic could handle this. If I'm not wrong, bitmasks can only be used to hide about 32 (or 64) bodies from each other currently. Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] : Add damping coefficient to material
Hi guys,
as discussed with Bruno in Barcelona I need different non-viscous damping
coefficients for different materials. I introduced this capability by adding a
variable damping to the base class material which is initialised with NaN. The
body class has a function getDampCoeff() and in NewtonIntegrator I use this
function in order to change the damping coefficients. When running some
examples
it seems that everything works fine. However, I just run 'yade --test' and it
gives me a seg fault:
testVelocity (yade.TestSimpleClump)
Clump: velocities of member assigned by NewtonIntegrator ... Segmentation
fault
I think I now where the problem is. In NewtonIntegrator I call something like:
if(!isnan(b-getDampCoeff())) dampcoeff=b-getDampCoeff();
where getDampCoeff() is defined in body.hpp as:
Real getDampCoeff() { return material-damping; };
I think the test doesn't have a material and therefore I get the seg fault.
Right? How can we fix this so that I can commit the code?
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
[Yade-dev] : yade --test fails after some changes in WirePM
Hi guys, I am just adding some new capabilities to my WirePM and doing some cleaning- up. When running some tests with the new code everything is fine. But when running 'yade --test' I get this: == FAIL: testSaveAllClasses (yade.TestIO) I/O: All classes can be saved and loaded with boost::serialization -- Traceback (most recent call last): File /home/thoeni/YADE-bzr/install/lib/yade-bzr2988/py/yade/tests/core.py, line 79, in testSaveAllClasses self.assert_(len(failed)==0,'Failed classes were: '+' '.join(failed)) AssertionError: Failed classes were: WireMat -- Any idea to what this could be related to? Thanks, Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : yade --test fails after some changes in WirePM
Hi, I found the problem but I don't know how I can fix it. At this stage I just committed a few changes. I had a similar issue last year and we solved it by adding if(strainStressValues.empty()) return; // uninitialized object, don't do nothing at all in postLoad of WireMat. strainStressValues is of type vectorVector2r. The point is I have two objects of this type now and one is optional so it can be uninitialized. How can I handle that? Thanks, Klaus On Fri, 13 Jan 2012 12:19:18 AM Anton Gladky wrote: Hi Klaus, it would be good if you show the diff (patch). Thanks. Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Avoid new contact detection between group of particle
Hi Bruno, On Fri, 13 Jan 2012 12:54:20 AM Bruno Chareyre wrote: Yes, it is like a deformable clumps. Something else I had in mined, the collider could check the material of two bodies and if it is of type WireMat then do nothing. What do you think? It would work but it would be ugly to include WireMat.hpp in the collider's code. I agree but I would need a quick solution. I'm thinking we could have a global selfInteractionMask, so that if mask1==mask2 !(mask1 selfInteractionMask), we skip. Please, can you give some more details? And how and where would this selfInteractionMask be implemented? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Avoid new contact detection between group of particle
Hi Bruno, On Mon, 16 Jan 2012 11:20:57 PM Bruno Chareyre wrote: It would work but it would be ugly to include WireMat.hpp in the collider's code. I agree but I would need a quick solution. The the sort of quick solution that you will never commit? Then try it. My bet is that, unfortunately, it will not give a very big speedup. The big task of the collider is to sort bounds, and it has to be done for all your elements anyway, since they can interact with other bodies. Quick and dirty ;-) But I prefer you solution anyway. I'm thinking we could have a global selfInteractionMask, so that if mask1==mask2 !(mask1 selfInteractionMask), we skip. Please, can you give some more details? And how and where would this selfInteractionMask be implemented? Collider.cpp:13, this is where masks are compared in bool maycollide(). You could test bodies masks with a self-interaction mask there, the new mask could be a member of the collider. Maybe try the first method before deciding if it's worth the additional test. I will try to implement it in the next couple of days. So you think there will be no speed-up? Any other suggestion how I can get some speed-up? Thanks ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] : yade.qt doc
Hi guys, there is something wrong with the docmuentation of module yade.qt. Nothing is shown on the doc site: https://yade-dem.org/doc/yade.qt.html and it's not listed in the index: https://yade-dem.org/doc/py-modindex.html Have a look. Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Avoid new contact detection between group of particle
Just tried it out and you are both right. There is almost no speedup. Thanks, Klaus On Tue, 17 Jan 2012 05:55:43 PM Anton Gladky wrote: I think, Bruno is right. There will unlikely be a speedup. But you can try anyway. Anton On Tue, Jan 17, 2012 at 7:23 AM, Klaus Thoeni klaus.tho...@gmail.com wrote: Hi Bruno, On Mon, 16 Jan 2012 11:20:57 PM Bruno Chareyre wrote: It would work but it would be ugly to include WireMat.hpp in the collider's code. I agree but I would need a quick solution. The the sort of quick solution that you will never commit? Then try it. My bet is that, unfortunately, it will not give a very big speedup. The big task of the collider is to sort bounds, and it has to be done for all your elements anyway, since they can interact with other bodies. Quick and dirty ;-) But I prefer you solution anyway. I'm thinking we could have a global selfInteractionMask, so that if mask1==mask2 !(mask1 selfInteractionMask), we skip. Please, can you give some more details? And how and where would this selfInteractionMask be implemented? Collider.cpp:13, this is where masks are compared in bool maycollide(). You could test bodies masks with a self-interaction mask there, the new mask could be a member of the collider. Maybe try the first method before deciding if it's worth the additional test. I will try to implement it in the next couple of days. So you think there will be no speed-up? Any other suggestion how I can get some speed-up? Thanks ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Add damping coefficient to material
Hi guys,
can anyone help me on this?
Klaus
On Thu, 12 Jan 2012 06:03:16 PM Klaus Thoeni wrote:
Hi guys,
as discussed with Bruno in Barcelona I need different non-viscous damping
coefficients for different materials. I introduced this capability by
adding a variable damping to the base class material which is initialised
with NaN. The body class has a function getDampCoeff() and in
NewtonIntegrator I use this function in order to change the damping
coefficients. When running some examples it seems that everything works
fine. However, I just run 'yade --test' and it gives me a seg fault:
testVelocity (yade.TestSimpleClump)
Clump: velocities of member assigned by NewtonIntegrator ... Segmentation
fault
I think I now where the problem is. In NewtonIntegrator I call something
like:
if(!isnan(b-getDampCoeff())) dampcoeff=b-getDampCoeff();
where getDampCoeff() is defined in body.hpp as:
Real getDampCoeff() { return material-damping; };
I think the test doesn't have a material and therefore I get the seg fault.
Right? How can we fix this so that I can commit the code?
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Add damping coefficient to material
Hi Anton,
I just had a look at py/tests/clump.py, that's the test which fails. I added
this after line 60 (before NewtonIntegrator is called):
for b in O.bodies: print b.material
and that's what I get:
FrictMat instance at 0x1014c10
None
So the second body has no material. I think it's more a problem in the test.
In a, lets say, real simulation the material always exists (or not?), so I am
not sure if checking for the material makes sense and it would be quit
inefficient.
However, I am not familiar with the testing stuff. Is there anyone who knows
why the second body gives 'None' for the material?
Klaus
On Thu, 19 Jan 2012 06:31:09 PM Anton Gladky wrote:
Real getDampCoeff() { return material-damping; };
Can you check here a material existence?
Anton
On Thu, Jan 19, 2012 at 8:14 AM, Klaus Thoeni klaus.tho...@gmail.com
wrote:
Hi guys,
can anyone help me on this?
Klaus
On Thu, 12 Jan 2012 06:03:16 PM Klaus Thoeni wrote:
Hi guys,
as discussed with Bruno in Barcelona I need different non-viscous
damping coefficients for different materials. I introduced this
capability by adding a variable damping to the base class material
which is initialised with NaN. The body class has a function
getDampCoeff() and in
NewtonIntegrator I use this function in order to change the damping
coefficients. When running some examples it seems that everything works
fine. However, I just run 'yade --test' and it gives me a seg fault:
testVelocity (yade.TestSimpleClump)
Clump: velocities of member assigned by NewtonIntegrator ...
Segmentation fault
I think I now where the problem is. In NewtonIntegrator I call something
like:
if(!isnan(b-getDampCoeff())) dampcoeff=b-getDampCoeff();
where getDampCoeff() is defined in body.hpp as:
Real getDampCoeff() { return material-damping; };
I think the test doesn't have a material and therefore I get the seg
fault. Right? How can we fix this so that I can commit the code?
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Add damping coefficient to material
Hi Anton,
actually it is the third body and it's a clump (isClump=True). Clumps should
have a material too, shouldn't they?
Klaus
On Thu, 19 Jan 2012 06:31:09 PM Anton Gladky wrote:
Real getDampCoeff() { return material-damping; };
Can you check here a material existence?
Anton
On Thu, Jan 19, 2012 at 8:14 AM, Klaus Thoeni klaus.tho...@gmail.com
wrote:
Hi guys,
can anyone help me on this?
Klaus
On Thu, 12 Jan 2012 06:03:16 PM Klaus Thoeni wrote:
Hi guys,
as discussed with Bruno in Barcelona I need different non-viscous
damping coefficients for different materials. I introduced this
capability by adding a variable damping to the base class material
which is initialised with NaN. The body class has a function
getDampCoeff() and in
NewtonIntegrator I use this function in order to change the damping
coefficients. When running some examples it seems that everything works
fine. However, I just run 'yade --test' and it gives me a seg fault:
testVelocity (yade.TestSimpleClump)
Clump: velocities of member assigned by NewtonIntegrator ...
Segmentation fault
I think I now where the problem is. In NewtonIntegrator I call something
like:
if(!isnan(b-getDampCoeff())) dampcoeff=b-getDampCoeff();
where getDampCoeff() is defined in body.hpp as:
Real getDampCoeff() { return material-damping; };
I think the test doesn't have a material and therefore I get the seg
fault. Right? How can we fix this so that I can commit the code?
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Add damping coefficient to material
I just creeated a clump in a real simulation , and indeed, material gives
'None'. So clumps have no material. Anyone knows why? Makes no sense to me.
Klaus
On Thu, 19 Jan 2012 09:51:38 PM Anton Gladky wrote:
Hmm, good question.
Maybe not. They consist of real spheres and those spheres should
have a material, I think.
Anton
On Thu, Jan 19, 2012 at 11:35 AM, Klaus Thoeni klaus.tho...@gmail.com
wrote:
Hi Anton,
actually it is the third body and it's a clump (isClump=True). Clumps
should have a material too, shouldn't they?
Klaus
On Thu, 19 Jan 2012 06:31:09 PM Anton Gladky wrote:
Real getDampCoeff() { return material-damping; };
Can you check here a material existence?
Anton
On Thu, Jan 19, 2012 at 8:14 AM, Klaus Thoeni klaus.tho...@gmail.com
wrote:
Hi guys,
can anyone help me on this?
Klaus
On Thu, 12 Jan 2012 06:03:16 PM Klaus Thoeni wrote:
Hi guys,
as discussed with Bruno in Barcelona I need different non-viscous
damping coefficients for different materials. I introduced this
capability by adding a variable damping to the base class material
which is initialised with NaN. The body class has a function
getDampCoeff() and in
NewtonIntegrator I use this function in order to change the damping
coefficients. When running some examples it seems that everything
works fine. However, I just run 'yade --test' and it gives me a seg
fault:
testVelocity (yade.TestSimpleClump)
Clump: velocities of member assigned by NewtonIntegrator ...
Segmentation fault
I think I now where the problem is. In NewtonIntegrator I call
something like:
if(!isnan(b-getDampCoeff())) dampcoeff=b-getDampCoeff();
where getDampCoeff() is defined in body.hpp as:
Real getDampCoeff() { return material-damping; };
I think the test doesn't have a material and therefore I get the seg
fault. Right? How can we fix this so that I can commit the code?
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Add damping coefficient to material
Solved the problem by checking if it is a clump:
Real getDampCoeff() { return (!Body::isClump) ? material-damping : NaN; };
However, I think we still have to sort out why clumps don't have a material!
I will commit the code, it might be useful to have different non-viscous
damping coefficients, or what do you think?
Klaus
On Thu, 19 Jan 2012 09:51:38 PM Anton Gladky wrote:
Hmm, good question.
Maybe not. They consist of real spheres and those spheres should
have a material, I think.
Anton
On Thu, Jan 19, 2012 at 11:35 AM, Klaus Thoeni klaus.tho...@gmail.com
wrote:
Hi Anton,
actually it is the third body and it's a clump (isClump=True). Clumps
should have a material too, shouldn't they?
Klaus
On Thu, 19 Jan 2012 06:31:09 PM Anton Gladky wrote:
Real getDampCoeff() { return material-damping; };
Can you check here a material existence?
Anton
On Thu, Jan 19, 2012 at 8:14 AM, Klaus Thoeni klaus.tho...@gmail.com
wrote:
Hi guys,
can anyone help me on this?
Klaus
On Thu, 12 Jan 2012 06:03:16 PM Klaus Thoeni wrote:
Hi guys,
as discussed with Bruno in Barcelona I need different non-viscous
damping coefficients for different materials. I introduced this
capability by adding a variable damping to the base class material
which is initialised with NaN. The body class has a function
getDampCoeff() and in
NewtonIntegrator I use this function in order to change the damping
coefficients. When running some examples it seems that everything
works fine. However, I just run 'yade --test' and it gives me a seg
fault:
testVelocity (yade.TestSimpleClump)
Clump: velocities of member assigned by NewtonIntegrator ...
Segmentation fault
I think I now where the problem is. In NewtonIntegrator I call
something like:
if(!isnan(b-getDampCoeff())) dampcoeff=b-getDampCoeff();
where getDampCoeff() is defined in body.hpp as:
Real getDampCoeff() { return material-damping; };
I think the test doesn't have a material and therefore I get the seg
fault. Right? How can we fix this so that I can commit the code?
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Add damping coefficient to material
-
angVel.cwise().abs().dot(m.cwise().abs())*dampcoeff*scene-
dt,nonviscDamp,nonviscDampIx,false);
}
// kinetic energy
Real Etrans=.5*state-mass*fluctVel.squaredNorm();
@@ -107,6 +111,10 @@
// clump members are handled inside clumps
if(unlikely(b-isClumpMember())) continue;
+ // check which damping coefficient to use
+ Real dampcoeff=damping;
+ if(!isnan(b-getDampCoeff()))
dampcoeff=b-getDampCoeff();
+
State* state=b-state.get(); const Body::id_t
id=b-getId();
Vector3r f=gravity*state-mass, m=Vector3r::Zero();
// clumps forces
@@ -146,7 +154,7 @@
if (state-blockedDOFs!=State::DOF_ALL) {
// linear acceleration
Vector3r
linAccel=computeAccel(f,state-mass,state-blockedDOFs);
- cundallDamp2nd(dt,f,fluctVel,linAccel);
+
cundallDamp2nd(dt,f,fluctVel,linAccel,dampcoeff);
//This is the convective term, appearing in the
time derivation
of Cundall/Thornton expression (dx/dt=velGrad*pos -
d²x/dt²=dvelGrad/dt*pos+velGrad*vel), negligible in many cases but not for
high speed large deformations (gaz or turbulent flow).
linAccel+=prevVelGrad*state-vel;
//finally update velocity
@@ -154,11 +162,11 @@
// angular acceleration
if(!useAspherical){ // uses angular velocity
Vector3r
angAccel=computeAngAccel(m,state-inertia,state-
blockedDOFs);
-
cundallDamp2nd(dt,m,state-angVel,angAccel);
+
cundallDamp2nd(dt,m,state-angVel,angAccel,dampcoeff);
state-angVel+=dt*angAccel;
} else { // uses torque
for(int i=0; i3; i++)
if(state-blockedDOFs
State::axisDOF(i,true)) m[i]=0; // block DOFs here
- cundallDamp1st(m,state-angVel);
+
cundallDamp1st(m,state-angVel,dampcoeff);
}
}
=== modified file pkg/dem/NewtonIntegrator.hpp
--- pkg/dem/NewtonIntegrator.hpp2011-09-20 10:58:18 +
+++ pkg/dem/NewtonIntegrator.hpp2012-01-12 05:26:05 +
@@ -22,8 +22,8 @@
class VelocityBins;
class NewtonIntegrator : public GlobalEngine{
- inline void cundallDamp1st(Vector3r force, const Vector3r vel);
- inline void cundallDamp2nd(const Real dt, const Vector3r force, const
Vector3r vel, Vector3r accel);
+ inline void cundallDamp1st(Vector3r force, const Vector3r vel, const
Real dampcoeff);
+ inline void cundallDamp2nd(const Real dt, const Vector3r force, const
Vector3r vel, Vector3r accel, const Real dampcoeff);
bool haveBins;
inline void leapfrogTranslate(State*, const Body::id_t id, const Real
dt); // leap-frog translate
inline void leapfrogSphericalRotate(State*, const Body::id_t id, const
Real dt); // leap-frog rotate of spherical body
On Thu, 19 Jan 2012 11:18:27 PM Anton Gladky wrote:
Could you, please, attach a diff first?
Thanks
Anton
On Thu, Jan 19, 2012 at 1:03 PM, Klaus Thoeni klaus.tho...@gmail.com
wrote:
Solved the problem by checking if it is a clump:
Real getDampCoeff() { return (!Body::isClump) ? material-damping : NaN;
};
However, I think we still have to sort out why clumps don't have a
material!
I will commit the code, it might be useful to have different non-viscous
damping coefficients, or what do you think?
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] : Add damping coefficient to material
Hi Bruno, hi Anton,
I think density scaling is not what I am looking for since I am interested in
real dynamic simulations. I need different damping parameters in
NewtonIntegrator for the block and the mesh. I have to consider free flight
under gravity so damping=0 (and I am interested in the real flight time). For
the mesh I have to consider additional energy absorption which is not
considered in my model via damping.
It is similar to b_damp() in PFC which is used to remove damping for certain
particle. I implemented it the same way now. The state has a member which is
true by default which means that damping is used. It can be set to false and
damping=0 will be used for this particle. So basically damping in
NewtonIntegrator can be activated and deactivated for individual particles.
@Anton: It has to be checked for all particles.
Here is the diff of my latest implementation, tell me what you think:
=== modified file core/State.hpp
--- core/State.hpp 2011-02-14 08:05:09 +
+++ core/State.hpp 2012-01-22 23:56:31 +
@@ -59,7 +59,8 @@
((Vector3r,inertia,Vector3r::Zero(),,Inertia of associated
body, in
local coordinate system.))
((Vector3r,refPos,Vector3r::Zero(),,Reference position))
((Quaternionr,refOri,Quaternionr::Identity(),,Reference
orientation))
- ((unsigned,blockedDOFs,,,[Will be overridden])),
+ ((unsigned,blockedDOFs,,,[Will be overridden]))
+ ((bool,isDamped,true,,Damping in :yref:`Newtonintegrator` can
be
deactivated for individual particles by setting this variable to FALSE. E.g.
damping is inappropriate for particles in free flight under gravity but it
might still be applicable to other particles in the same simulation.)),
/* additional initializers */
((pos,se3.position))
((ori,se3.orientation)),
=== modified file pkg/dem/NewtonIntegrator.cpp
--- pkg/dem/NewtonIntegrator.cpp2011-11-30 17:39:33 +
+++ pkg/dem/NewtonIntegrator.cpp2012-01-22 23:56:31 +
@@ -11,17 +11,18 @@
#includeyade/pkg/dem/Clump.hpp
#includeyade/pkg/common/VelocityBins.hpp
#includeyade/lib/base/Math.hpp
YADE_PLUGIN((NewtonIntegrator));
CREATE_LOGGER(NewtonIntegrator);
// 1st order numerical damping
-void NewtonIntegrator::cundallDamp1st(Vector3r force, const Vector3r vel){
- for(int i=0; i3; i++) force[i]*=1-damping*Mathr::Sign(force[i]*vel[i]);
+void NewtonIntegrator::cundallDamp1st(Vector3r force, const Vector3r vel,
const Real dampcoeff){
+ for(int i=0; i3; i++)
force[i]*=1-dampcoeff*Mathr::Sign(force[i]*vel[i]);
}
// 2nd order numerical damping
-void NewtonIntegrator::cundallDamp2nd(const Real dt, const Vector3r force,
const Vector3r vel, Vector3r accel){
- for(int i=0; i3; i++) accel[i]*= 1 - damping*Mathr::Sign (
force[i]*(vel[i] + 0.5*dt*accel[i]) );
+void NewtonIntegrator::cundallDamp2nd(const Real dt, const Vector3r force,
const Vector3r vel, Vector3r accel, const Real dampcoeff){
+ for(int i=0; i3; i++) accel[i]*= 1 - dampcoeff*Mathr::Sign (
force[i]*(vel[i] + 0.5*dt*accel[i]) );
}
Vector3r NewtonIntegrator::computeAccel(const Vector3r force, const Real
mass, int blockedDOFs){
@@ -39,11 +40,13 @@
void NewtonIntegrator::updateEnergy(const shared_ptrBody b, const State*
state, const Vector3r fluctVel, const Vector3r f, const Vector3r m){
assert(b-isStandalone() || b-isClump());
- // always positive dissipation, by-component: |F_i|*|v_i|*damping*dt (|
T_i|*|ω_i|*damping*dt for rotations)
- if(damping!=0.){
- scene-energy-
add(fluctVel.cwise().abs().dot(f.cwise().abs())*damping*scene-
dt,nonviscDamp,nonviscDampIx,/*non-incremental*/false);
+ // check if damping for this body is activated
+ Real dampcoeff=(state-isDamped ? damping : 0);
+ // always positive dissipation, by-component: |F_i|*|v_i|*dampcoeff*dt
(|
T_i|*|ω_i|*dampcoeff*dt for rotations)
+ if(dampcoeff!=0.){
+ scene-energy-
add(fluctVel.cwise().abs().dot(f.cwise().abs())*dampcoeff*scene-
dt,nonviscDamp,nonviscDampIx,/*non-incremental*/false);
// when the aspherical integrator is used, torque is damped
instead of
ang acceleration; this code is only approximate
- scene-energy-add(state-
angVel.cwise().abs().dot(m.cwise().abs())*damping*scene-
dt,nonviscDamp,nonviscDampIx,false);
+ scene-energy-add(state-
angVel.cwise().abs().dot(m.cwise().abs())*dampcoeff*scene-
dt,nonviscDamp,nonviscDampIx,false);
}
// kinetic energy
Real Etrans=.5*state-mass*fluctVel.squaredNorm();
@@ -106,9 +109,13 @@
YADE_PARALLEL_FOREACH_BODY_BEGIN(const shared_ptrBody b,
scene-bodies)
{
// clump members are handled inside clumps
if(unlikely(b-isClumpMember())) continue;
-
+
State*
Re: [Yade-dev] : Add damping coefficient to material
Hi Chiara,
thanks for your comment. I am not after viscous damping either. But I think
the current implementation does exactly what I want, it's the same as the PFC
option b_damp(). So I can deactivate the damping coefficient for individual
bodies.
I can commit the code if anyone is interested , after the diff has been
approved ;-)
Klaus
On Mon, 23 Jan 2012 08:44:02 PM Chiara wrote:
On 23/01/12 00:12, Klaus Thoeni wrote:
Hi Bruno, hi Anton,
I think density scaling is not what I am looking for since I am
interested in real dynamic simulations. I need different damping
parameters in NewtonIntegrator for the block and the mesh. I have to
consider free flight under gravity so damping=0 (and I am interested in
the real flight time). For the mesh I have to consider additional energy
absorption which is not considered in my model via damping.
If you are not after any density scaling, why damping in
NewtonIntegrator should be acceptable in a realistic dynamic situation?
Would not be easier/more meaningful for you to implement damping inside
your contact model? Sorry, just curious.
Chiara
It is similar to b_damp() in PFC which is used to remove damping for
certain particle. I implemented it the same way now. The state has a
member which is true by default which means that damping is used. It can
be set to false and damping=0 will be used for this particle. So
basically damping in NewtonIntegrator can be activated and deactivated
for individual particles.
@Anton: It has to be checked for all particles.
Here is the diff of my latest implementation, tell me what you think:
=== modified file core/State.hpp
--- core/State.hpp 2011-02-14 08:05:09 +
+++ core/State.hpp 2012-01-22 23:56:31 +
@@ -59,7 +59,8 @@
((Vector3r,inertia,Vector3r::Zero(),,Inertia of associated
body,
in
local coordinate system.))
((Vector3r,refPos,Vector3r::Zero(),,Reference position))
((Quaternionr,refOri,Quaternionr::Identity(),,Reference
orientation))
- ((unsigned,blockedDOFs,,,[Will be overridden])),
+ ((unsigned,blockedDOFs,,,[Will be overridden]))
+ ((bool,isDamped,true,,Damping in :yref:`Newtonintegrator` can
be
deactivated for individual particles by setting this variable to FALSE.
E.g. damping is inappropriate for particles in free flight under gravity
but it might still be applicable to other particles in the same
simulation.)),
/* additional initializers */
((pos,se3.position))
((ori,se3.orientation)),
=== modified file pkg/dem/NewtonIntegrator.cpp
--- pkg/dem/NewtonIntegrator.cpp2011-11-30 17:39:33 +
+++ pkg/dem/NewtonIntegrator.cpp2012-01-22 23:56:31 +
@@ -11,17 +11,18 @@
#includeyade/pkg/dem/Clump.hpp
#includeyade/pkg/common/VelocityBins.hpp
#includeyade/lib/base/Math.hpp
YADE_PLUGIN((NewtonIntegrator));
CREATE_LOGGER(NewtonIntegrator);
// 1st order numerical damping
-void NewtonIntegrator::cundallDamp1st(Vector3r force, const Vector3r
vel){ - for(int i=0; i3; i++)
force[i]*=1-damping*Mathr::Sign(force[i]*vel[i]); +void
NewtonIntegrator::cundallDamp1st(Vector3r force, const Vector3r vel,
const Real dampcoeff){
+ for(int i=0; i3; i++)
force[i]*=1-dampcoeff*Mathr::Sign(force[i]*vel[i]);
}
// 2nd order numerical damping
-void NewtonIntegrator::cundallDamp2nd(const Real dt, const Vector3r
force, const Vector3r vel, Vector3r accel){
- for(int i=0; i3; i++) accel[i]*= 1 - damping*Mathr::Sign (
force[i]*(vel[i] + 0.5*dt*accel[i]) );
+void NewtonIntegrator::cundallDamp2nd(const Real dt, const Vector3r
force, const Vector3r vel, Vector3r accel, const Real dampcoeff){
+ for(int i=0; i3; i++) accel[i]*= 1 - dampcoeff*Mathr::Sign (
force[i]*(vel[i] + 0.5*dt*accel[i]) );
}
Vector3r NewtonIntegrator::computeAccel(const Vector3r force, const
Real
mass, int blockedDOFs){
@@ -39,11 +40,13 @@
void NewtonIntegrator::updateEnergy(const shared_ptrBody b, const
State*
state, const Vector3r fluctVel, const Vector3r f, const Vector3r
m){
assert(b-isStandalone() || b-isClump());
- // always positive dissipation, by-component: |F_i|*|v_i|*damping*dt
(|
T_i|*|ω_i|*damping*dt for rotations)
- if(damping!=0.){
- scene-energy-
add(fluctVel.cwise().abs().dot(f.cwise().abs())*damping*scene-
dt,nonviscDamp,nonviscDampIx,/*non-incremental*/false);
+ // check if damping for this body is activated
+ Real dampcoeff=(state-isDamped ? damping : 0);
+ // always positive dissipation, by-component: |F_i|*|v_i|*dampcoeff*dt
(| T_i|*|ω_i|*dampcoeff*dt for rotations)
+ if(dampcoeff!=0.){
+ scene-energy-
add(fluctVel.cwise().abs().dot(f.cwise().abs
Re: [Yade-dev] : Add damping coefficient to material
Hi guys,
thanks a lot for your suggestions. I just committed the code and I think it
looks very good now.
Klaus
On Mon, 23 Jan 2012 11:08:59 PM Bruno Chareyre wrote:
Ok, I understand.
I like your diff more than the previous one. :)
Still one suggestion: this additional parameter in the damping functions
is useless:
+
cundallDamp2nd(dt,m,state-angVel,angAccel,dampcoeff);
In your code, dampCoeff will be either Newton::damping or zero.
So, it would be better to just write this, avoiding the function call
and additional parameter:
if (state-isDamped) cundallDamp2nd(dt,m,state-angVel,angAccel)
Then I agree to commit.
Bruno
On 23/01/12 11:48, Klaus Thoeni wrote:
Hi Chiara,
thanks for your comment. I am not after viscous damping either. But I
think the current implementation does exactly what I want, it's the same
as the PFC option b_damp(). So I can deactivate the damping coefficient
for individual bodies.
I can commit the code if anyone is interested , after the diff has been
approved ;-)
Klaus
On Mon, 23 Jan 2012 08:44:02 PM Chiara wrote:
On 23/01/12 00:12, Klaus Thoeni wrote:
Hi Bruno, hi Anton,
I think density scaling is not what I am looking for since I am
interested in real dynamic simulations. I need different damping
parameters in NewtonIntegrator for the block and the mesh. I have to
consider free flight under gravity so damping=0 (and I am interested in
the real flight time). For the mesh I have to consider additional
energy absorption which is not considered in my model via damping.
If you are not after any density scaling, why damping in
NewtonIntegrator should be acceptable in a realistic dynamic situation?
Would not be easier/more meaningful for you to implement damping inside
your contact model? Sorry, just curious.
Chiara
It is similar to b_damp() in PFC which is used to remove damping for
certain particle. I implemented it the same way now. The state has a
member which is true by default which means that damping is used. It
can be set to false and damping=0 will be used for this particle. So
basically damping in NewtonIntegrator can be activated and deactivated
for individual particles.
@Anton: It has to be checked for all particles.
Here is the diff of my latest implementation, tell me what you think:
=== modified file core/State.hpp
--- core/State.hpp2011-02-14 08:05:09 +
+++ core/State.hpp2012-01-22 23:56:31 +
@@ -59,7 +59,8 @@
((Vector3r,inertia,Vector3r::Zero(),,Inertia of
associated body,
in
local coordinate system.))
((Vector3r,refPos,Vector3r::Zero(),,Reference
position))
((Quaternionr,refOri,Quaternionr::Identity(),,Reference
orientation))
- ((unsigned,blockedDOFs,,,[Will be overridden])),
+ ((unsigned,blockedDOFs,,,[Will be overridden]))
+ ((bool,isDamped,true,,Damping in :yref:`Newtonintegrator` can
be
deactivated for individual particles by setting this variable to FALSE.
E.g. damping is inappropriate for particles in free flight under
gravity but it might still be applicable to other particles in the
same simulation.)),
/* additional initializers */
((pos,se3.position))
((ori,se3.orientation)),
=== modified file pkg/dem/NewtonIntegrator.cpp
--- pkg/dem/NewtonIntegrator.cpp 2011-11-30 17:39:33 +
+++ pkg/dem/NewtonIntegrator.cpp 2012-01-22 23:56:31 +
@@ -11,17 +11,18 @@
#includeyade/pkg/dem/Clump.hpp
#includeyade/pkg/common/VelocityBins.hpp
#includeyade/lib/base/Math.hpp
YADE_PLUGIN((NewtonIntegrator));
CREATE_LOGGER(NewtonIntegrator);
// 1st order numerical damping
-void NewtonIntegrator::cundallDamp1st(Vector3r force, const
Vector3r vel){ - for(int i=0; i3; i++)
force[i]*=1-damping*Mathr::Sign(force[i]*vel[i]); +void
NewtonIntegrator::cundallDamp1st(Vector3r force, const Vector3r
vel, const Real dampcoeff){
+ for(int i=0; i3; i++)
force[i]*=1-dampcoeff*Mathr::Sign(force[i]*vel[i]);
}
// 2nd order numerical damping
-void NewtonIntegrator::cundallDamp2nd(const Real dt, const Vector3r
force, const Vector3r vel, Vector3r accel){
- for(int i=0; i3; i++) accel[i]*= 1 - damping*Mathr::Sign (
force[i]*(vel[i] + 0.5*dt*accel[i]) );
+void NewtonIntegrator::cundallDamp2nd(const Real dt, const Vector3r
force, const Vector3r vel, Vector3r accel, const Real dampcoeff){
+ for(int i=0; i3; i++) accel[i]*= 1 - dampcoeff*Mathr::Sign (
force[i]*(vel[i] + 0.5*dt*accel[i]) );
}
Vector3r NewtonIntegrator::computeAccel(const Vector3r force, const
Real
mass, int blockedDOFs){
@@ -39,11 +40,13 @@
void NewtonIntegrator::updateEnergy
Re: [Yade-dev] [Yade-users] Optimized contact detection available
Hi Bruno, thanks for having a look at my scripts! I know that the clump is disappearing sometimes on the display but the simulation itself seems to be ok so I never had a closer look at it. But it was good you did ;-) I just had a look at rev 3010 and now I got some speed up too which is great. I will get rid of the GravityEngine and just use NewtonIntegrator::gravity. Thanks again, Klaus On Tue, 31 Jan 2012 08:02:30 AM Bruno Chareyre wrote: (Don't use Newton::gravity though, it breaks something in your script and I'm still investigating). It is not related to the new Newton::gravity, it only revealed another bug in eigen's quaternions. In your script, Klaus, the clump sometimes disappear, did you notice? It is because the axisAngle conversion of clump members orientation is nan from time to time Actually, no... The nan quaternions break the display but they seem to be harmless. The problem was https://bugs.launchpad.net/yade/+bug/923929 It is fixed in bzr3009. Below is what I get with your 02_net-wall_par.py script Klaus (-j2, default collider setting, for 3009 this is without gravity engine). The speedup is only 25%. As said before, it can't be much better since the collider takes only 14% of total time initially. Still, all engines are a bit faster. :) Bruno bzr2999 Name Count TimeRel. time --- ForceResetter 20050 7068191us3.38% InsertionSortCollider 1855 29429129us 14.06% InteractionLoop 20050 92135400us 44.03% gravity 20050 23556447us 11.26% newton 20050 57063846us 27.27% TOTAL 209253016us 100.00% bzr3009 Name Count TimeRel. time --- ForceResetter 20050 7087997us4.68% InsertionSortCollider 634 11046290us7.29% InteractionLoop 20050 80287582us 52.98% newton 20050 53130390us 35.06% TOTAL 151552261us 100.00% ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 931263] [NEW] localhost info
Public bug reported: When running a simulation, which has already some pre-history (e.g. load a simulation which has done already 10 iterations and run some more simulations), in batch mode some information in localhost info are wrong. I guess the average iterations per seconds include the iterations from the loaded state. Therefore, the value is far to high and the estimate for the finishing time/date is as well wrong. When running without batch mode the controller is showing the correct value. ** Affects: yade Importance: Low Status: New -- You received this bug notification because you are a member of Yade developers, which is the registrant for Yade. https://bugs.launchpad.net/bugs/931263 Title: localhost info Status in Yet Another Dynamic Engine: New Bug description: When running a simulation, which has already some pre-history (e.g. load a simulation which has done already 10 iterations and run some more simulations), in batch mode some information in localhost info are wrong. I guess the average iterations per seconds include the iterations from the loaded state. Therefore, the value is far to high and the estimate for the finishing time/date is as well wrong. When running without batch mode the controller is showing the correct value. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/931263/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Bug 931263] Re: localhost info
Hi Anton, well done! The information shown by the localhost are fine now. The only thing which is still strange is that the estimated day/time when finished is wrong even if the iter/sec is more or less constant. It gives dates like 20 March whereas the simulation is finished in 5 minutes. Towards the end of the simulation (90%) it's getting more realistic. The same problem exists for simulations starting from the beginning. Not sure how the time/date is estimated. But since value iter/sec is correct it shouldn't behave so strange. Thanks, Klaus On Tue, 14 Feb 2012 08:07:57 AM Anton Gladky wrote: I hope r3025 will fix the bug. -- You received this bug notification because you are a member of Yade developers, which is the registrant for Yade. https://bugs.launchpad.net/bugs/931263 Title: localhost info Status in Yet Another Dynamic Engine: Fix Released Bug description: When running a simulation, which has already some pre-history (e.g. load a simulation which has done already 10 iterations and run some more simulations), in batch mode some information in localhost info are wrong. I guess the average iterations per seconds include the iterations from the loaded state. Therefore, the value is far to high and the estimate for the finishing time/date is as well wrong. When running without batch mode the controller is showing the correct value. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/931263/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Bug 931263] Re: localhost info
Yes, thanks Anton! On Tue, 14 Feb 2012 05:42:19 PM Anton Gladky wrote: Hi Klaus, it should be ok in r3026. There was a typo in a formulation. Thanks for pointing that out. Anton 2012/2/14 Klaus Thoeni 931...@bugs.launchpad.net: Hi Anton, well done! The information shown by the localhost are fine now. The only thing which is still strange is that the estimated day/time when finished is wrong even if the iter/sec is more or less constant. It gives dates like 20 March whereas the simulation is finished in 5 minutes. Towards the end of the simulation (90%) it's getting more realistic. The same problem exists for simulations starting from the beginning. Not sure how the time/date is estimated. But since value iter/sec is correct it shouldn't behave so strange. Thanks, Klaus On Tue, 14 Feb 2012 08:07:57 AM Anton Gladky wrote: I hope r3025 will fix the bug. -- You received this bug notification because you are subscribed to Yade. https://bugs.launchpad.net/bugs/931263 Title: localhost info Status in Yet Another Dynamic Engine: Fix Released Bug description: When running a simulation, which has already some pre-history (e.g. load a simulation which has done already 10 iterations and run some more simulations), in batch mode some information in localhost info are wrong. I guess the average iterations per seconds include the iterations from the loaded state. Therefore, the value is far to high and the estimate for the finishing time/date is as well wrong. When running without batch mode the controller is showing the correct value. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/931263/+subscriptions -- You received this bug notification because you are a member of Yade developers, which is the registrant for Yade. https://bugs.launchpad.net/bugs/931263 Title: localhost info Status in Yet Another Dynamic Engine: Fix Released Bug description: When running a simulation, which has already some pre-history (e.g. load a simulation which has done already 10 iterations and run some more simulations), in batch mode some information in localhost info are wrong. I guess the average iterations per seconds include the iterations from the loaded state. Therefore, the value is far to high and the estimate for the finishing time/date is as well wrong. When running without batch mode the controller is showing the correct value. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/931263/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Bug 918948] Re: yade.qt documentation missing
Thanks Remi, it's working now. On Thu, 16 Feb 2012 03:34:45 AM Rémi wrote: Hi, Le 08/02/2012 23:15, Klaus Thoeni a écrit : actually at some stage it was working, see bzr2704: https://www.yade-dem.org/sphinx/yade.qt.html I don't know if in the mean time something changed in the doc generation. This was old way automatic building, not on buildbot. Doc is now generated using xvfb (a virtual x server), it should contains qt specific parts. Cheers, rémi Cheers, Klaus On Wed, 8 Feb 2012 10:02:38 PM Chareyre wrote: It is not very easy I'm afraid. I see windows manipulation in the Viewer constructor itself. Since generating the documentation needs to instanciate one object of each class, we are stuck I think (not sure though). A workaround would be to generate the documentation on one of these server slots that allow graphical sessions. Is that possible? -- You received this bug notification because you are a member of Yade developers, which is the registrant for Yade. https://bugs.launchpad.net/bugs/918948 Title: yade.qt documentation missing Status in Yet Another Dynamic Engine: New Bug description: There is something wrong with the documentation of module yade.qt. Nothing is shown on the doc site: https://yade-dem.org/doc/yade.qt.html and it's not listed in the index: https://yade-dem.org/doc/py-modindex.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/918948/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] own compiled boost
Hi guys, as you might have noticed I am trying to run yade on a Red Hat server. However, saving and loading of simulations is not working. My guess is it could be related to the boost version used on the server (1.41.0-11) so I compiled version 1.46.1 in /usr/local. After adding LIBPATH = '/usr/local/boost_1_46_1/stage/lib' and CPPPATH = '/usr/local/boost_1_46_1' to my scons.profile I could compile the code. However, when launching yade I have the following problem now. Welcome to Yade bzr2999 Traceback (most recent call last): File ./yade-bzr2999, line 118, in module import yade File /home/kt748/YADE-bzr/install/lib/yade-bzr2999/py/yade/__init__.py, line 58, in module import boot ImportError: libboost_system.so.1.46.1: cannot open shared object file: No such file or directory But libboost_system.so.1.46.1 exists in /usr/local/boost_1_46_1/. Any suggestions? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] own compiled boost
Thanks Anton, but LD_LIBRARY_PATH is not an option in scons.profile. Any other guesses? On Mon, 20 Feb 2012 05:39:02 PM Anton Gladky wrote: Hi Klaus, try adding LD_LIBRARY_PATH='/usr/local/boost_1_46_1' Sorry, just a guess. Never tried. Anton 2012/2/20 Klaus Thoeni klaus.tho...@newcastle.edu.au: Hi guys, as you might have noticed I am trying to run yade on a Red Hat server. However, saving and loading of simulations is not working. My guess is it could be related to the boost version used on the server (1.41.0-11) so I compiled version 1.46.1 in /usr/local. After adding LIBPATH = '/usr/local/boost_1_46_1/stage/lib' and CPPPATH = '/usr/local/boost_1_46_1' to my scons.profile I could compile the code. However, when launching yade I have the following problem now. Welcome to Yade bzr2999 Traceback (most recent call last): File ./yade-bzr2999, line 118, in module import yade File /home/kt748/YADE-bzr/install/lib/yade-bzr2999/py/yade/__init__.py, line 58, in module import boot ImportError: libboost_system.so.1.46.1: cannot open shared object file: No such file or directory But libboost_system.so.1.46.1 exists in /usr/local/boost_1_46_1/. Any suggestions? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] own compiled boost
Hi Anton, the path to the dynamic libraries was incomplete. I solved it with: export D_LIBRARY_PATH=/usr/local/boost_1_46_1/stage/lib And yade finally works. So the problem was really related to the boost version. So what do you think, should update the documentation for the installation and point out that boost 1.42 or later is required? Well it was not working with 1.41.0 on Red Hat and 1.42.0 works on my ubuntu machine. Guys, what do you think? Thanks again, Klaus On Tue, 21 Feb 2012 08:18:02 AM Anton Gladky wrote: Try to start yade: export LD_LIBRARY_PATH=/usr/local/boost_1_46_1; yade Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 850864] Re: strange facet-sphere behaviour
Hi Bruno, I might have found a student which can work on it. What do you think? Is it tricky? I didn't have a look at it since last time we talked about it and it seams the bug is still existing. Let me know. -- You received this bug notification because you are a member of Yade developers, which is the registrant for Yade. https://bugs.launchpad.net/bugs/850864 Title: strange facet-sphere behaviour Status in Yet Another Dynamic Engine: Confirmed Bug description: See https://answers.launchpad.net/yade/+question/171223 Spheres that are exactly on an edge between facets behave strangely. Maybe related to other (closed, but never solved) bugs in sphere- facet. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/850864/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Bug 850864] Re: strange facet-sphere behaviour
Ok, this job might be too big for the studend indeed. On Wed, 11 Apr 2012 11:45:52 PM Bruno Chareyre wrote: Well, basically, it is not possible to fix this problem with the current logic, where each facet is an independant body. We need to consider a triangulated surface as one entity and define contacts differently if they are on facets, edges, or vertices. In order to do that, we need a well designed data structure defining the connectivity of facets, and used by Ig functors to track the contacts passing from one facet to the other. The problem is similar as in chained cylinder, but in 2D (while chained cylinders are 1D). It would be a big step, but it is not a small job. Bruno On 11/04/12 13:08, Klaus Thoeni wrote: Hi Bruno, I might have found a student which can work on it. What do you think? Is it tricky? I didn't have a look at it since last time we talked about it and it seams the bug is still existing. Let me know. ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Removing scons
Well, I thought so too, sice I saw your commits but if a go on https://yade-dem.org/doc/installation.html everything is still with scons and bzr. Maybe because of this: This documentation decribes Yade version 2012-06-24.git-00a175d / 2012-06-24.git-00a175d. So the doc on the server needs to be re-compiled. BTW, how often is this done? On Wed, 4 Jul 2012 03:33:30 PM Anton Gladky wrote: Hi Klaus, scons stuff is already replaced by cmake in docs. Anton 2012/7/4 Klaus Thoeni klaus.tho...@gmail.com: Hi guys, before removing scons I would strongly suggest to update the documentation. We should also get rid of all the bzr stuff if we really want to stay with git. Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 850864] Re: strange facet-sphere behaviour
Hi guys, I just found this paper: http://onlinelibrary.wiley.com/doi/10.1002/nme.4487/abstract Maybe it could be one way to implement the contact detection between spheres and facets in yade. What do you think? Klaus -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/850864 Title: strange facet-sphere behaviour Status in Yet Another Dynamic Engine: Won't Fix Bug description: See https://answers.launchpad.net/yade/+question/171223 Spheres that are exactly on an edge between facets behave strangely. Maybe related to other (closed, but never solved) bugs in sphere- facet. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/850864/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [yade/trunk] ad4f51: various wire contact laws available now, add refer...
Branch: refs/heads/master Home: https://github.com/yade/trunk Commit: ad4f512969efc02fa092966817a79f696667eb26 https://github.com/yade/trunk/commit/ad4f512969efc02fa092966817a79f696667eb26 Author: Klaus Thoeni klaus.tho...@gmail.com Date: 2013-06-24 (Mon, 24 Jun 2013) Changed paths: A scripts/checks-and-tests/checks/checkWirePM.py Log Message: --- various wire contact laws available now, add reference with details, add a check script for the wire model ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [yade/trunk] f14104: various wire contact laws available now (new versi...
Branch: refs/heads/master Home: https://github.com/yade/trunk Commit: f1410403c3b0f0828b7bb4106b108886bfd3d1a8 https://github.com/yade/trunk/commit/f1410403c3b0f0828b7bb4106b108886bfd3d1a8 Author: Klaus Thoeni klaus.tho...@gmail.com Date: 2013-06-24 (Mon, 24 Jun 2013) Changed paths: M doc/references.bib M doc/yade-articles.bib M pkg/dem/WirePM.cpp M pkg/dem/WirePM.hpp Log Message: --- various wire contact laws available now (new version), add reference with details ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Yade does not start, linker problem?
Hi guys I just updated one of my machines and compiled yade. Everything went smoothly but when I try to run yade I get the following: thoeni@thoeni:~/YADE-git/master/build$ yade Welcome to Yade 2013-06-21.git-1e52860 Traceback (most recent call last): File /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860, line 115, in module import yade File /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module import boot ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol: _ZTVN4yade6SphereE To me it seems like a liking error but I was not able to fix it. I am running kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine with the same operating system but cmake 2.8.7 and it is working. Any suggestions? BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to upgrade? Thnaks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Yade does not start, linker problem?
I actually did re-run cmake. I even deleted everything in my build directory to be sure. So I guess this is not the problem. Any other ideas? On Tuesday 25 June 2013 10:48:33 Bruno Chareyre wrote: Did you re-run cmake? When new cpp files are added (and it was the case recently) it is necessary. B On 25/06/13 08:49, Klaus Thoeni wrote: Hi guys I just updated one of my machines and compiled yade. Everything went smoothly but when I try to run yade I get the following: thoeni@thoeni:~/YADE-git/master/build$ yade Welcome to Yade 2013-06-21.git-1e52860 Traceback (most recent call last): File /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860, line 115, in module import yade File /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module import boot ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol: _ZTVN4yade6SphereE To me it seems like a liking error but I was not able to fix it. I am running kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine with the same operating system but cmake 2.8.7 and it is working. Any suggestions? BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to upgrade? Thnaks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] yade --check
I added a check script: scripts/checks-and-tests/checks/checkWirePM.py Now when running yade --check it should automatically be detected by checkList.py. There is no need to add it to a list, right? But it's not running. Is something wrong with my script? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Yade does not start, linker problem?
No, I am not using yade from packages. I am only running my own compiled version. Could it be a problem with the cmake version? Is anyone using cmake 2.8.9? What else could it be? On Tuesday 25 June 2013 11:43:17 Anton Gladky wrote: Do you have installed yade from packages on that machine? It can so happen, that the shared libraries are taken from the packaged Yade version, but you try to use the compiled one. Anton 2013/6/25 Klaus Thoeni klaus.tho...@newcastle.edu.au: I actually did re-run cmake. I even deleted everything in my build directory to be sure. So I guess this is not the problem. Any other ideas? On Tuesday 25 June 2013 10:48:33 Bruno Chareyre wrote: Did you re-run cmake? When new cpp files are added (and it was the case recently) it is necessary. B On 25/06/13 08:49, Klaus Thoeni wrote: Hi guys I just updated one of my machines and compiled yade. Everything went smoothly but when I try to run yade I get the following: thoeni@thoeni:~/YADE-git/master/build$ yade Welcome to Yade 2013-06-21.git-1e52860 Traceback (most recent call last): File /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860 , line 115, in module import yade File /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module import boot ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol: _ZTVN4yade6SphereE To me it seems like a liking error but I was not able to fix it. I am running kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine with the same operating system but cmake 2.8.7 and it is working. Any suggestions? BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to upgrade? Thnaks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5735 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Yade does not start, linker problem?
Hi Jan I usually delete everything in my build directory before compiling a new version. I guess that should do the job as well, or not? Thanks Klaus On Tuesday 25 June 2013 08:54:19 you wrote: Hi Klaus, I met the same problem some time ago.. After what time did you do the update? sometimes make clean is needed if there are some significant changes. HTH Jan 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com Hi guys I just updated one of my machines and compiled yade. Everything went smoothly but when I try to run yade I get the following: thoeni@thoeni:~/YADE-git/master/build$ yade Welcome to Yade 2013-06-21.git-1e52860 Traceback (most recent call last): File /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860, line 115, in module import yade File /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module import boot ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol: _ZTVN4yade6SphereE To me it seems like a liking error but I was not able to fix it. I am running kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine with the same operating system but cmake 2.8.7 and it is working. Any suggestions? BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to upgrade? Thnaks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] yade --check
Ok, now it's running as well on my machine. So, if I understand it right you have to touch CMakeLists.txt when you add new files, right? So it's not enough to delete your build and install directory. Thanks Anton On Tuesday 25 June 2013 11:59:43 Anton Gladky wrote: It is running [1]. Just do touch CMakeLists.txt [1] https://yade-dem.org/buildbot/builders/yade-full/builds/1997/steps/test_1/l ogs/stdio Anton 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com: I added a check script: scripts/checks-and-tests/checks/checkWirePM.py Now when running yade --check it should automatically be detected by checkList.py. There is no need to add it to a list, right? But it's not running. Is something wrong with my script? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Yade does not start, linker problem?
No, I am executing the right file. However, some new hint. When comparing the local directory install/lib/x86_64- linux-gnu/yade-2013-06-15.git-e88d195/py to another working one I can see that in my directory all pyc-files are missing. I guess this is the problem. But why are they missing? Has it something to to with PYTHONPATH or so? On Tuesday 25 June 2013 12:51:57 you wrote: Yes, if you delete everything and cmake - make from scratch, it is stronger than make clean :-) but I have no idea in your case.. Try also to delete the yade executable, is it possible that you are executing different file? Jan 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com Hi Jan I usually delete everything in my build directory before compiling a new version. I guess that should do the job as well, or not? Thanks Klaus On Tuesday 25 June 2013 08:54:19 you wrote: Hi Klaus, I met the same problem some time ago.. After what time did you do the update? sometimes make clean is needed if there are some significant changes. HTH Jan 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com Hi guys I just updated one of my machines and compiled yade. Everything went smoothly but when I try to run yade I get the following: thoeni@thoeni:~/YADE-git/master/build$ yade Welcome to Yade 2013-06-21.git-1e52860 Traceback (most recent call last): File /home/thoeni/YADE-git/master/install/bin/yade-2013-06-21.git-1e52860 , line 115, in module import yade File /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/py/yade/__init__.py, line 65, in module import boot ImportError: /home/thoeni/YADE-git/master/install/lib/x86_64-linux- gnu/yade-2013-06-21.git-1e52860/libcore.so: undefined symbol: _ZTVN4yade6SphereE To me it seems like a liking error but I was not able to fix it. I am running kubuntu 12.04 with gcc 4.6.3 and cmake 2.8.9. I have another machine with the same operating system but cmake 2.8.7 and it is working. Any suggestions? BTW, is anyone running yade on ubuntu 12.10 or 13.04? Do you recommend to upgrade? Thnaks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Yade does not start, linker problem?
No, I don't set it manually. I am just guessing because I encountered this problem after I tried to compile yade's documentation and after installing GenGeo by compiling the sources, and both are somehow using PYTHONPATH. Well I am not sure what's going on. It seams that the pyc files are created when launching yade the first time, so it is not related to that since yade is not starting. Any other guess? On Tuesday 25 June 2013 13:55:41 Anton Gladky wrote: 2013/6/25 Klaus Thoeni klaus.tho...@gmail.com: Has it something to to with PYTHONPATH or so? Do you set it explicitly? It can cause problems. Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Yade does not start, linker problem?
I tried to install and build in another directory. I even created a new user to see if it is related to my local settings. But I still have the same issue. I am actually considering to re-install kubuntu. Any recommendations on what version I should use (12.04 or 13.04)? Thanks Klaus On Wednesday 26 June 2013 21:26:03 Anton Gladky wrote: Hmm, difficult to say, what is going on. Did you try to install and build in some other directory? Anton 2013/6/26 Klaus Thoeni klaus.tho...@gmail.com: Files are attached attached. ldd gives a similar error. On Wednesday 26 June 2013 08:25:26 Anton Gladky wrote: ldd -d /home/thoeni/YADE-git/master/install/lib/x86_64-linux-gnu/yade-2013-06-21 .g it-1e52860/libcore.so ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Yade does not start, linker problem?
Hi Anton thank you very much, it's working now. Just in time ;-) Why didn't anyone else have this problem? How can we avoid such problems in the future? Thanks again Klaus On Monday 01 July 2013 21:09:14 Anton Gladky wrote: Hi all, Klaus, if you have not yet reinstalled the system, please check the latest 34ba150-commit, it should fix your problem. It was a bug, which became visible after 1e52860. Christian has used functions from libplugins (e.g. pkg/* -directory), but Clumps are in libcore, which are not linked against libplugins, but libplugins were linked against libcore... So, to escape any other confusions and cross- and over-linkage I merged libplugins, libsupport and libcore into libyade, It should fix all issues. Thanks all for contribution. Anton 2013/7/1 Jan Stránský honzik.stran...@gmail.com: Hi guys, did you find the solution? I did a fresh installation from the scratch ending with exactly the same error as Klaus.. Thanks Jan 2013/6/27 Anton Gladky gladky.an...@gmail.com 2013/6/27 Klaus Thoeni klaus.tho...@gmail.com: I am actually considering to re-install kubuntu. Any recommendations on what version I should use (12.04 or 13.04)? From my point of view there are not so much changes in scientific packages between these versions, because Debian was frozen in this period. Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] plot.show() and pylab.show() block konsole
Hi guys I run one of the example scripts, i.e. /examples/test/psd.py. The script uses pylab to plot the psd curve. However, once the plots are shown the ipython konsole is blocked. One has to close all the windows/figures including Yade's cotroller and viewer in order to access it again. Same applies if I use yade.plot.show(). Can anyone reproduce this behaviour? Is it a bug in yade or mathplotlib? I think it was fine on my old installation so the problem might be related to matplotlib. Now I am running kubuntu 12.04.2 with matplotlib 1.1.1. Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Some other clump issues
Hi guys I really like the idea of having clump properties updated, thanks Christian. However, I found a little problem: line 121-122 in Clump.cpp. Clumps with no physical overlap are detected with intersecting=true, i.e. try this and you have to wait quite a while: O.bodies.appendClumped(regularOrtho(inAlignedBox((0.,0.,0.), (2,2,2)),radius=0.1,gap=0.0)) There should be no overlap but it seems that updateProperties is called. I guess it is because of the numerical rounding error in line 121. The check in line 122 un0 should probably be changed to something like un-0.001*min(r1,r2) with a tolerance. What do you think? Secondly, I think we should leave it up to the user to define if he wants to update the properties. It makes sense to let the user choose the divisor for the regular grid and maybe divisor=0 could mean no update. Any additional thought on this? Klaus P.S.: Thanks Bruno for starting the clump discussion ;-) ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Logging and debugging
Hi guys
log4cxx feature and yade.log module are not available any more, right? So how
do you print your logs? I am used to use something like this in my scripts:
import yade.log
yade.log.setLevel('TheClassOfWhichLoggerYouWantToSet',yade.log.TRACE)
One can cmake with -DDEBUG=ON which should compile yade in debug mode. Before
cmake yade --debug was used to run yade in debug mode. It seems that this
option is not valid any more. So how do you guys run debug and optimized at
the same time? Do you define an other INSTALL_PREFIX for debug?
Thanks
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Logging and debugging
Hi Anton
On Thursday 22 August 2013 07:50:28 Anton Gladky wrote:
Hi Klaus,
2013/8/22 Klaus Thoeni klaus.tho...@gmail.com
Hi guys
log4cxx feature and yade.log module are not available any more, right? So
how
do you print your logs? I am used to use something like this in my
scripts:
import yade.log
yade.log.setLevel('TheClassOfWhichLoggerYouWantToSet',yade.log.TRACE)
setLevel does not work any more.
So what can I use to see the log output? Is there an other way for doing it
now? Or is this feature completely removed? If so all the LOGs in the code are
for nothing now.
One can cmake with -DDEBUG=ON which should compile yade in debug mode.
Before
cmake yade --debug was used to run yade in debug mode. It seems that
this
option is not valid any more. So how do you guys run debug and optimized
at
the same time? Do you define an other INSTALL_PREFIX for debug?
Yes, you should have 2 different build-places and install debug and
optimized
versions in different paths or with different suffixes.
I see. Do I have to set something else? I just tried to put some std::cerr
output in the code and I compiled with debug but it is not appearing. I am
calling the right version of yade because I removed everything else before ;-)
BTW, do you think it is possible that yade tells you that you are running it
in debug mode? Maybe something like: Welcome to Yade 2013-08-15.git-4ef35b0
(debug)?
Thanks
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Logging and debugging
Hi Anton On Thursday 22 August 2013 08:33:58 Anton Gladky wrote: 2013/8/22 Klaus Thoeni klaus.tho...@gmail.com: So what can I use to see the log output? Is there an other way for doing it now? Or is this feature completely removed? If so all the LOGs in the code are for nothing now. LOG_WARN, LOG_ERROR, LOG_FATAL should work [1]. I see. Do I have to set something else? I just tried to put some std::cerr output in the code and I compiled with debug but it is not appearing. When I debug the code, I am doing exactly the same. It should appear or this part of code is not executed. I thought so too but this seems not to be the case at least for me. It's working e.g. for classes like the contact law but if I put some outputs in methods of NewtonIntegrator or Shop which are definitely called it's not working. Even after recompiling debug from scratch. I have no idea what's going on here. Any idea? BTW, do you think it is possible that yade tells you that you are running it in debug mode? Maybe something like: Welcome to Yade 2013-08-15.git-4ef35b0 (debug)? Need to think about that. Debug-mode is just adding so-called debug-symbols. It means, that during the crash you should get some more information about that. That is a normal practice for the software.See, how many packages are having -dbg suffix. Most of them are just those symbols. [1] https://github.com/yade/trunk/blob/master/lib/base/Logging.hpp#L22 Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] bool MatchMaker
Hi guys it seems that MatchMakers are working with Real only. I tried something like this: O.engines=[ ... [Law2_ScGeom_MindlinPhys_Mindlin(includeMoment=MatchMaker(matches=((mat1,mat1,True), (mat1,mat2,False] ... ] which gives the following error: TypeError: No registered converter was able to produce a C++ rvalue of type bool from this Python object of type MatchMaker When looking into the code it is obvious because the whole class is defined for Real only. Is there a workaround for Booleans? If not, any idea how to implement it? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Logging and debugging
Hi Anton, I put a std::cerr in the first line of Newtonintegrator::action() in Newtonintegrator.cpp. Any script with NewtonIntegrator should call this method. Or am I wrong? Klaus On Wednesday 28 August 2013 07:43:48 Anton Gladky wrote: Could you, please, send a minimal script to localize the problem? Anton 2013/8/27 Klaus Thoeni klaus.tho...@gmail.com: Hi Anton On Thursday 22 August 2013 08:33:58 Anton Gladky wrote: 2013/8/22 Klaus Thoeni klaus.tho...@gmail.com: So what can I use to see the log output? Is there an other way for doing it now? Or is this feature completely removed? If so all the LOGs in the code are for nothing now. LOG_WARN, LOG_ERROR, LOG_FATAL should work [1]. I see. Do I have to set something else? I just tried to put some std::cerr output in the code and I compiled with debug but it is not appearing. When I debug the code, I am doing exactly the same. It should appear or this part of code is not executed. I thought so too but this seems not to be the case at least for me. It's working e.g. for classes like the contact law but if I put some outputs in methods of NewtonIntegrator or Shop which are definitely called it's not working. Even after recompiling debug from scratch. I have no idea what's going on here. Any idea? BTW, do you think it is possible that yade tells you that you are running it in debug mode? Maybe something like: Welcome to Yade 2013-08-15.git-4ef35b0 (debug)? Need to think about that. Debug-mode is just adding so-called debug-symbols. It means, that during the crash you should get some more information about that. That is a normal practice for the software.See, how many packages are having -dbg suffix. Most of them are just those symbols. [1] https://github.com/yade/trunk/blob/master/lib/base/Logging.hpp#L22 Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] bool MatchMaker
Hi Bruno On Wednesday 28 August 2013 12:07:40 Bruno Chareyre wrote: Hi Klaus, There are other problems in this line. * The parameter itself has to be declared as a matchMaker. For instance Ip2_FrictMat_FrictMat_MindlinPhys::en is a MatchMaker (or None, then default code is used). includeMoment is not a MatchMaker, so it will not work. * The code itself has to use the object as a MatchMaker, not as a builtin type, for instance in HertzMinlin.cpp: Real logE = log((*en)(mat1-id,mat2-id)); instead of Real logE = log(en); So, it will clearly not work to pick a random attribute of an engine and make it a MatchMaker in a python script. It needs to be already anticipated by the c++ side. I completely forgot about it but changing this should not be a problem. The definition just needs to be changed to: (shared_ptrMatchMaker,includeMoment,,,bool to consider rolling resistance) * The last thing, is that MM are indeed only returning scalar values, but it should not be a problem to convert Real to bool. I could use 0 and 1 instead of False and True in the python script: includeMoment=MatchMaker(matches=((mat1,mat1,1), (mat1,mat2,0 In the code we can use something like this to convert the Real to a Boolean: ((*includeMoment)(mat1-id,mat2-id) != 0) but this probably brakes the conventional way: includeMoment=True What do you think? I see that we don't have a real example script for matchMakers. That is bad... This script for example shows the use of MatchMaker: examples/spheresFactory.py Bruno On 28/08/13 04:18, Klaus Thoeni wrote: Hi guys it seems that MatchMakers are working with Real only. I tried something like this: O.engines=[ ... [Law2_ScGeom_MindlinPhys_Mindlin(includeMoment=MatchMaker(matches=((mat1,m at1,True), (mat1,mat2,False] ... ] which gives the following error: TypeError: No registered converter was able to produce a C++ rvalue of type bool from this Python object of type MatchMaker When looking into the code it is obvious because the whole class is defined for Real only. Is there a workaround for Booleans? If not, any idea how to implement it? Thanks Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] bool MatchMaker
I completely forgot about it but changing this should not be a problem. The definition just needs to be changed to: (shared_ptrMatchMaker,includeMoment,,,bool to consider rolling resistance) Yes. I could use 0 and 1 instead of False and True in the python script: includeMoment=MatchMaker(matches=((mat1,mat1,1), (mat1,mat2,0 In the code we can use something like this to convert the Real to a Boolean: ((*includeMoment)(mat1-id,mat2-id) != 0) but this probably brakes the conventional way: includeMoment=True What do you think? I don't see what it would break. Remember to keep the behavior unchanged in case includeMoment is none (in c++ the pointer will be null). Well, ((*includeMoment)(mat1-id,mat2-id) != 0) should work as well for the case if includeMoment is none which corresponds to the default (false) at the moment. But includeMoment=True or False in the python script should give a problem or at least a compiler warning in ((*includeMoment)(mat1-id,mat2-id) != 0), because conversion of bool with int. Don't you think so? Another option is to make MatchMakers for krot and ktwist and set them to 0 so the moment will be 0. It might be an easier solution but not the most efficient. ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] bool MatchMaker
Another option is to make MatchMakers for krot and ktwist and set them to
0 so the moment will be 0. It might be an easier solution but not the
most efficient.
The best thing I can imagine is to add a MatchMaker that would not
replace includeMoment, let's call it momentMatch here.
if (includeMoment (!momentMatch || (*momentMatch)(mat1,mat2)){
// ... the moment code
}
Sounds good to me, thanks for that.
BTW, don't you think it would make sense to make MatchMakers for most of the
parameters in the IP2 functors? It would give more flexibility when working
with different materials.
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Bug 1229783] Re: packs.py example hangs due to appendClumped command
Hi guys loading a clump takes ages indeed (I have clumps with 100 particles) but not sure if this is a bug. Maybe there is something wrong with the loops? Klaus On Thursday 26 September 2013 08:55:19 Bruno Chareyre wrote: A question for Christian: If I have a clump with, let's say, 20 particles. Will there be 20 computations of inertia (each time we add a new member) or only one? We should find a default behavior that do not take ages to compute anyway, be it at the price of big approximations. Bruno -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1229783 Title: packs.py example hangs due to appendClumped command Status in Yet Another Dynamic Engine: Invalid Bug description: The examples/packs/packs.py hangs in line 46 [1] because of appendClumped command. Changing it to append fixes the problem. So, it seems, appendClump has infinite loop somewhere. [1] https://github.com/yade/trunk/blob/master/examples/packs/packs.py#L46 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1229783/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5735 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3713: Remove pkg/dem/DomainLimiter.*
Hi guys the DomainLimiter is very useful as well. It removes particles which exit a defined region from the simulation. I am using it. What is the problem with it? Klaus On Tuesday 15 October 2013 12:37:18 Bruno Chareyre wrote: Hi Anton, I don't know what DomainLimiter is (or was). In the same file however there is LawTester which is used in a script and is a very interesting piece of work (from Vaçlav). I think we should keep that one. Bruno On 14/10/13 23:48, nore...@launchpad.net wrote: revno: 3713 committer: Anton Gladky gladky.an...@gmail.com timestamp: Mon 2013-10-14 22:51:11 +0200 message: Remove pkg/dem/DomainLimiter.* It seems, the code is unmaintained and requires too much RAM for compilation. Feel free to recover it, if it is necessary. removed: pkg/dem/DomainLimiter.cpp pkg/dem/DomainLimiter.hpp -- lp:yade https://code.launchpad.net/~yade-pkg/yade/git-trunk Your team Yade developers is subscribed to branch lp:yade. To unsubscribe from this branch go to https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5735 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] gmplib and other libraries
Hi guys, do you know where gmplib is used in yade? A grep for gmp doesn't give any results and it seams that yade is running without the library even if cmake is complaining/warning. Any idea? If it is not used we should get rid of it in the install requirements. What do you think about extending the list of external libraries with our optionals like CGAL, OpenBLAS etc. It would be nice to have a complete list. Cheers Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] gmplib and other libraries
do you know where gmplib is used in yade? A grep for gmp doesn't give any results and it seams that yade is running without the library even if cmake is complaining/warning. Any idea? If it is not used we should get rid of it in the install requirements. Sure, go ahead and remove it. It was probably used some time ago, but no more in the current code. Ok, I will. What do you think about extending the list of external libraries with our optionals like CGAL, OpenBLAS etc. It would be nice to have a complete list. I am not sure, what you mean. cgal and openblas are in fact optional. If they are not in the system, it will disable some corresponding features, but will not break the compilation. Or what you meant? I meant the list on yade's installation web page under Prerequisites in addition to the sudo apt-get install list. Cheers Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] gmplib and other libraries
Hi guys it's deleted from the install list. It will indeed be installed with libcgal- dev. So the question is if we should get rid of the FindGMP.cmake as well since it depends on libcgal. Cheers Klaus On Tuesday 29 October 2013 15:54:35 Anton Gladky wrote: True, Bruno. libcgal-dev depends on libgmp-dev [1]. So, if you install libcgal-dev, libgmp-dev will be installed automatically. So I do not see any reasons to install libgmp-dev explicitly if we do not use it directly in the code. [1] http://packages.debian.org/sid/libcgal-dev Anton 2013/10/29 Bruno Chareyre bruno.chare...@hmg.inpg.fr: gmp lib was a dependency of cgal some time ago, and it probably still is. The link may be implicit so you don't see the problem. Did you try to uninstall the lib from your system and start yade? ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Bug 1250928] [NEW] Compilation from source probably miss some documentation
Hi Bruno it probably depends on which options you are using when compiling. I am not using the ppa and everything is working for me on 12.04. Nevertheless, you are right the ppa should probably be mentioned in the installation section. But I don't think it is mandatory. Cheers Klaus On Wednesday 13 November 2013 16:23:49 Bruno Chareyre wrote: Public bug reported: It seems the instructions for installing prerequisites [1] will fail on ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile anyway leads to a few cmake warnings but it will let one build. Then boot failure because of missing lib (didn't do the build myself, I've seen the result on a colleagues computer). The bug is that the ppa is not mentionned anywhere on the installation page. If anyone confirm I can update the doc, though I'm not sure if this situation is for 12.04 only, or if the ppa should be considered mandatory for all platforms. [1] https://yade-dem.org/doc/installation.html#prerequisites ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1250928 Title: Compilation from source probably miss some documentation Status in Yet Another Dynamic Engine: New Bug description: It seems the instructions for installing prerequisites [1] will fail on ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile anyway leads to a few cmake warnings but it will let one build. Then boot failure because of missing lib (didn't do the build myself, I've seen the result on a colleagues computer). The bug is that the ppa is not mentionned anywhere on the installation page. If anyone confirm I can update the doc, though I'm not sure if this situation is for 12.04 only, or if the ppa should be considered mandatory for all platforms. [1] https://yade-dem.org/doc/installation.html#prerequisites To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1250928/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5735 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Bug 1250928] Re: Compilation from source probably miss some documentation
Yes, yade-users ppa is available. However, I have not installed metis. But this shouldn't have an influence on this specific problem with lapack, or I am wrong? I can't see any other package on the ppa which might be relevant. Anyway, I will see if I can reproduce the problem on my desktop. Klaus On Tuesday 19 November 2013 11:00:13 Bruno Chareyre wrote: @Klaus Is it with yade-users ppa available? In that case it should work like a charm in my experience. Bruno -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1250928 Title: Compilation from source probably miss some documentation Status in Yet Another Dynamic Engine: New Bug description: It seems the instructions for installing prerequisites [1] will fail on ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile anyway leads to a few cmake warnings but it will let one build. Then boot failure because of missing lib (didn't do the build myself, I've seen the result on a colleagues computer). The bug is that the ppa is not mentionned anywhere on the installation page. If anyone confirm I can update the doc, though I'm not sure if this situation is for 12.04 only, or if the ppa should be considered mandatory for all platforms. [1] https://yade-dem.org/doc/installation.html#prerequisites To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1250928/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp -- Dr. Klaus Thoeni - Centre for Geotechnical and Materials Modelling Civil, Surveying and Environmental Engineering - Engineering Building EA The University of Newcastle, Callaghan, NSW 2308, Australia web: http://www.newcastle.edu.au/research-centre/cgmm phone: +61 (0)2 4921 5735 -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1250928 Title: Compilation from source probably miss some documentation Status in Yet Another Dynamic Engine: New Bug description: It seems the instructions for installing prerequisites [1] will fail on ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile anyway leads to a few cmake warnings but it will let one build. Then boot failure because of missing lib (didn't do the build myself, I've seen the result on a colleagues computer). The bug is that the ppa is not mentionned anywhere on the installation page. If anyone confirm I can update the doc, though I'm not sure if this situation is for 12.04 only, or if the ppa should be considered mandatory for all platforms. [1] https://yade-dem.org/doc/installation.html#prerequisites To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1250928/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1250928] Re: Compilation from source probably miss some documentation
Hi Bruno, the only library of you list I have installed at the moment is: libsuitesparse-dev 1:3.4.0-2ubuntu3 Not sure why openblas is giving trouples on my machines. Just to verify, my Kubuntu version is 12.04.3 LTS. Are you using the same? Here the python verison installed on my machines: python 2.7.3-0ubuntu2.2 python-numpy1:1.6.1-6ubuntu1 Well, if I am the nly one having this problem we can close the bug. I don't need this feature at the moment and I am alread looking forward to the 14.04 LTS Cheers Klaus -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1250928 Title: Compilation from source probably miss some documentation Status in Yet Another Dynamic Engine: Invalid Bug description: It seems the instructions for installing prerequisites [1] will fail on ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile anyway leads to a few cmake warnings but it will let one build. Then boot failure because of missing lib (didn't do the build myself, I've seen the result on a colleagues computer). The bug is that the ppa is not mentionned anywhere on the installation page. If anyone confirm I can update the doc, though I'm not sure if this situation is for 12.04 only, or if the ppa should be considered mandatory for all platforms. [1] https://yade-dem.org/doc/installation.html#prerequisites To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1250928/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1250928] Re: Compilation from source probably miss some documentation
@Bruno Well I copy pasted the sudo apt-get install from the instructions. But this did't work in my case. I got the cmake error I showed above. Nervertheless, un-installing libopenblas-base solved the problem for me. That's whay it's not installed ;-) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1250928 Title: Compilation from source probably miss some documentation Status in Yet Another Dynamic Engine: Invalid Bug description: It seems the instructions for installing prerequisites [1] will fail on ubuntu 12.04 if yade-users ppa is not enabled first. Trying to compile anyway leads to a few cmake warnings but it will let one build. Then boot failure because of missing lib (didn't do the build myself, I've seen the result on a colleagues computer). The bug is that the ppa is not mentionned anywhere on the installation page. If anyone confirm I can update the doc, though I'm not sure if this situation is for 12.04 only, or if the ppa should be considered mandatory for all platforms. [1] https://yade-dem.org/doc/installation.html#prerequisites To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1250928/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] Why Ip2 functors must be symmetric?
Hi guys
is there I reason why we only have symmetric Ip2 functors? I recently committed
a contact law with non-symmetric Ip2 functor
(Ip2_FrictMat_FrictViscoMat_FrictViscoPhys) but at the moment it is not working
as expected. It turns out that the reason is in InteractionLoop.cpp line 122
and following (and maybe somewhere else too):
// IPhysDispatcher
if(!I-functorCache.phys){
I-functorCache.phys=physDispatcher-getFunctor2D(b1-material,b2-material,swap);
assert(!swap); // InteractionPhysicsEngineUnits are
symmetric
}
It assumes swap is always false. Is there a reason why we are not doing it the
same way as for the Ig2 functors (see lines 90-104)? Well, if there is no
reason I would like to change it to something like this:
bool swap=false;
// IPhysDispatcher
if(!I-functorCache.phys){
I-functorCache.phys=physDispatcher-getFunctor2D(b1-material,b2-material,swap);
}
if(swap){I-swapOrder();}
// body pointers must be updated, in case we swapped
const shared_ptrBody bb1=swap?b2:b1;
const shared_ptrBody bb2=swap?b1:b2;
What do you think? Would this change work or am I missing something?
Further, I can see that in the Ig2 functors we have a goReverse. Is this ever
called? A quick grep did not show any calls but only definitions. Not sure, but
is this something we can get rid of?
Cheers,
Klaus
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3804: new simple contact law with normal viscose damping which allows to specify kn and ks/kn in Ip2
Sorry for late reply, but here my thoughts. I think a separation at material
level would be better, i.e. FrictMat inherits ViscElastMat which inherits
something like ViscElCapillarMat. I think it would make sense because not all
visco-elastic materials have capillar forces. What do you think?
In the case of CapillaryPhys none of the parameters is stored in FrictMat.
There seams to be a bit of inconsistency. Same with kn and kt. Should the
material have these parameters or the Ip2 functor? IMO, stiffness is related to
a specific contact and should therefore be in the Ip2.
I think we need to make a decision. I think we should keep it one way and not
mix it.
Klaus
On Tuesday 28 January 2014 15:25:04 Bruno Chareyre wrote:
On 28/01/14 14:10, Anton Gladky wrote:
That is true. I actually moved an implementations into
ViscoelasticCapillarPM [1], but parameters are still in the parent
class. Any suggestions how to improve it are very welcome.
If I don't miss something, it could be just like CapillaryPhys, which
inherits from FrictPhys.
The cappilar version of the contact law would read
Law2_ScGeom_ViscElPhys_Capillar::go(...) {
Law2_ScGeom_ViscElPhys_Basic::go(...);
// add capillary forces here
...
}
If not possible (*), you can extract code blocks from
Law2_ScGeom_ViscElPhys_Basic::go and put them in separate functions that
can be called in child classes.
Law2_ScGeom_ViscElPhys_Capillar::go(...) {
Law2_ScGeom_ViscElPhys_Basic::computeForceTorque(...,f);
// add capillary forces here
...
}
(*) one problem I anticipate is that Law2_ScGeom_ViscElPhys_Basic::go()
could erase an interaction that is still alive wrt the capillary model.
Hence the split of go() in different functions.
Bruno
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Why Ip2 functors must be symmetric?
Hi Bruno I think non-symmetric functors are rarely necessary since most combinations can be dealt with via inheritance (e.g. Frict vs CohFrict is interpreted as Frict vs. Frict since CohFrict inherits from Frict). Exactly, but what if you want it to behave it like a cohesive contact. This is not possible at the current stage. So non-symmetric Ip2 functors would make sense here, right? And looking at the variety of material we have (some are not inherited from FrictMat) I can see some more benefits. However, I am like you, I don't see the reason why it is asserted symmetric. I suggest to try your idea after removing this constraint and see if it works as accepted. Ok, I will try. Any idea about the goReverse? Can it be removed? Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3804: new simple contact law with normal viscose damping which allows to specify kn and ks/kn in Ip2
Hi Bruno Sorry for late reply, but here my thoughts. I think a separation at material level would be better, i.e. FrictMat inherits ViscElastMat which inherits something like ViscElCapillarMat. I think it would make sense because not all visco-elastic materials have capillar forces. What do you think? I think this is also what Anton had in mind. Base types should be free of capillary things, which are very specific. So you agree that the parameters should already be separated at material level, correct? In the case of CapillaryPhys none of the parameters is stored in FrictMat. And it is good that way, isn't it? FrictMat has the contact parameters, CapillaryPhys inherits them and add the capillary parameters. It should be the same for ViscEl, as you suggest. There seams to be a bit of inconsistency. Same with kn and kt. Should the material have these parameters or the Ip2 functor? IMO, stiffness is related to a specific contact and should therefore be in the Ip2. I don't get your point here. Ip2's are not supposed to have parameters at all, they convert material data to interaction data (e.g. they convert Material::Young to IPhys::kn). I know many Ip2 still have a few physical parameters but it is only lazy implementation, we should avoid that. Ip2_Frict and Ip2_CohFrict, for instance have no parameters at all. The point is that MatchMaker only work for Ip2 functors and to me they really make sense for some specific cases (especially if you have many different materials). And as I said before, contact stiffness is a property of the contact and not the material. We generally calculate it as a harmonic average of the Youngs' modulus of the two materials in contact but in some cases you might want to define it explicitly. In this cases I think it should be defined in the Ip2 functor, or not? Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3804: new simple contact law with normal viscose damping which allows to specify kn and ks/kn in Ip2
Hi Anton, are you planning to split the parameters at material level (see discussion with Bruno)? Thanks Klaus On Tuesday 28 January 2014 14:10:53 Anton Gladky wrote: On 28/01/14 01:14, Klaus Thoeni wrote: Last but not least I think we could probably split visco-elastic and capillary parameters. That is true. I actually moved an implementations into ViscoelasticCapillarPM [1], but parameters are still in the parent class. Any suggestions how to improve it are very welcome. [1] https://github.com/yade/trunk/blob/master/pkg/dem/ViscoelasticCapillarPM.cp p Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Why Ip2 functors must be symmetric?
Hi Bruno Why would you define a body with FrictPhys if is supposed to have a cohesive behavior with others? You can just give CohFrictPhys to everyone. That's what I did so far but it is not always possible. Any idea about the goReverse? Can it be removed? Maybe not removed. I think it is necessary, precisely because we can have non-symmetric functors. If you swap ids in Ip2 you may break the work of the Ig2. The go reverse is here for this reason (handling non-symmetric cases without forcing a specific ordering of id1/id2 and without the need to define to functors). The comment in line 98 in IntersectionLoop.cpp says: // arguments for the geom functor are in the reverse order (dispatcher would normally call goReverse). // we don't remember the fact that is reverse, so we swap bodies within the interaction // and can call go in all cases In fact, it seams goReverse is never called because bodies are swapped before. So maybe we can get rid of it??? Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] Why Ip2 functors must be symmetric?
Hi Bruno Swapping for the Ig2 and swapping for the Ip2 are two different things. This comment at L98 applies for geometry only. Swapping for the Ip2 after computing the geometry would break everything (contact normal should be inverted, etc.) It is also what L125 suggests: assert(!swap); it is clear that the Ip2 must NOT swap. OK, I can see the point here. The only way to go without swapping is to call goReverse, as far as I understand. Ok, so we have two options: a) swap for Ig2 (as it is now) and therefore get rid of goReverse in Ig2, and call go/goReverse for Ip2 b) get rid of swap for Ig2 and call go/goReverse in both cases (maybe more consistent?) What do you think? Something I couldn't find out, do we need to do something like if(swap) goReverse() else go() or is this handled automatically? Removing goReverse was maybe an objective of Vaclav, then the present situation would be half way to it. Not sure. That's probably the case. Looking into WooDem reveals that there is no goReverse. BTW, it there any chance to get Vaclav's opinion on this topic? Thanks a lot Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] clump discretization/integrateInertia
Hi guys, is there a reason why we have two parameters here? Wouldn't one be enough? E.i. we just use discretization and if discretization==0 than the properties are not updated. What do you thing? Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [yade-dev] clump discretization/integrateInertia
Hi guys, is there a reason why we have two parameters here? Wouldn't one be enough? E.i. we just use discretization and if discretization==0 than the properties are not updated. What do you thing? Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] parallel collider - testing needed
Hi Bruno, 2/ Hyperthreading is completely useless for heavy computing tasks, actually even bad, as your results suggest. I did some tests by enabling and disabling hyperthreading some time ago. Conclusions: always disable hyperthreading, as you say it makes no sense for the kind of thinks we are doing. Maybe we should mention it somewhere on our web page. Any suggestions where? Benchmarking 8 threads via this technique is irrelevant for this reason. What I would really like to see is how the collider scales with 8 non-virtual cores and more. I think they can do that in Freiberg and Newcastle (in Grenoble as well, in fact, I just didn't find the time). I did some testing with --performance on our grid on 3 different nodes and with various numbers of cores. I am rerunning the test with 50 particles at the moment and will try to post a summary of all the results here or on the wiki later. In the mean time some results of our slow AMD Opteron Processor 6282 SE: yade -j4 5037 spheres, velocity= 94.8073682494 +- 3.55139591623 % 25103 spheres, velocity= 27.7389795715 +- 8.63375047506 % 50250 spheres, velocity= 16.0519684282 +- 5.60688183622 % 100467 spheres, velocity= 6.67235752786 +- 8.84758076674 % 200813 spheres, velocity= 2.66158958354 +- 7.70653861779 % yade-pc -j4 5037 spheres, velocity= 78.264605326 +- 4.06741633055 % 25103 spheres, velocity= 26.0879865929 +- 2.61754448363 % 50250 spheres, velocity= 15.7245773611 +- 2.24679654566 % 100467 spheres, velocity= 7.64762330727 +- 2.59000324319 % 200813 spheres, velocity= 3.64194000319 +- 1.80798282427 % yade -j8 5037 spheres, velocity= 138.024763661 +- 14.7299332104 % 25103 spheres, velocity= 35.7526851013 +- 4.24184671794 % 50250 spheres, velocity= 22.0071042904 +- 8.36195041437 % 100467 spheres, velocity= 11.1704832541 +- 11.725537817 % 200813 spheres, velocity= 3.54394003786 +- 5.48119712335 % yade-pc -j8 5037 spheres, velocity= 133.311680084 +- 1.88168292497 % 25103 spheres, velocity= 34.3688804144 +- 7.43189318211 % 50250 spheres, velocity= 21.3620031259 +- 3.8532356508 % 100467 spheres, velocity= 11.3218727607 +- 3.77428592406 % 200813 spheres, velocity= 6.16209240352 +- 6.24680400297 % yade -j16 5037 spheres, velocity= 71.8232644642 +- 41.7059425388 % 25103 spheres, velocity= 24.6342039841 +- 3.98148164778 % 50250 spheres, velocity= 16.1247061321 +- 4.73981941981 % 100467 spheres, velocity= 9.23509237236 +- 2.14822969955 % 200813 spheres, velocity= 2.91721702399 +- 3.88145803663 % yade-pc -j16 5037 spheres, velocity= 129.908588625 +- 15.6874714595 % 25103 spheres, velocity= 33.526601121 +- 13.7594343427 % 50250 spheres, velocity= 17.7898704143 +- 7.7469432427 % 100467 spheres, velocity= 11.3877154372 +- 1.74832633634 % 200813 spheres, velocity= 6.95545612967 +- 2.35988760251 % yade -j32 5037 spheres, velocity= 59.0283160736 +- 51.2569740982 % 25103 spheres, velocity= 18.7622567759 +- 6.54660223453 % 50250 spheres, velocity= 12.3588048445 +- 8.49295845839 % 100467 spheres, velocity= 7.6569548227 +- 6.71719242602 % 200813 spheres, velocity= 2.47982732752 +- 10.4129796959 % yade-pc -j32 5037 spheres, velocity= 88.990043 +- 15.7295668423 % 25103 spheres, velocity= 18.1857423869 +- 1.17387945175 % 50250 spheres, velocity= 12.6321967406 +- 5.31792620843 % 100467 spheres, velocity= 8.98513348696 +- 4.48699885744 % 200813 spheres, velocity= 6.12495571697 +- 1.48933071382 % Summary for 20 particles: - -j4: scale =1.37 - -j8: scale =1.74 - -j16: scale =2.38 - -j32: scale =2.47 These numbers might look differently on our Intel nodes, I still have to check. What I need also before pushing to trunk is more testing with real scripts, not just --performance. I only covered a narrow range of situations with my own scripts, I would like to be sure that it will not break in other cases. Maybe ask mister Fu, he really seems to be keen on increasing his computing scale ;-) Cheers Klaus ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] parallel collider - testing needed
https://yade-dem.org/wiki/Performance_Test Wow! Speed x6 for 500k particules?! It was definitely worth trying with larger numbers, it changes the picture completely when the last points are included. Very nice page. Could you also give some absolute timings for completness? A convenient value could be the Cundall's number: Np*Nt/Tcpu With Np number of bodies, Nt number of iterations, Tcpu computation time. I just updated the page: https://yade-dem.org/wiki/Performance_Test ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1290194] [NEW] O.reset() does not free memory
Public bug reported: O.reset() does not free the memory, i.e. if you run a series of simulations in a loop the memory usage is accumulating. Here is a script which reproduces the issue (it should affect all versions): # -*- coding: utf-8 import subprocess numberTests = 10 for z in range(numberTests): O.reset() O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0)) print number of bodies:, len(O.bodies) cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0].strip() print Yade memory usage: , meminfo, kB cmd = egrep 'MemFree' /proc/meminfo process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0] print meminfo sys.exit(0) ** Affects: yade Importance: Low Status: New ** Changed in: yade Importance: Undecided = Low -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1290194 Title: O.reset() does not free memory Status in Yet Another Dynamic Engine: New Bug description: O.reset() does not free the memory, i.e. if you run a series of simulations in a loop the memory usage is accumulating. Here is a script which reproduces the issue (it should affect all versions): # -*- coding: utf-8 import subprocess numberTests = 10 for z in range(numberTests): O.reset() O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0)) print number of bodies:, len(O.bodies) cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0].strip() print Yade memory usage: , meminfo, kB cmd = egrep 'MemFree' /proc/meminfo process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0] print meminfo sys.exit(0) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1290194/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
[Yade-dev] [Bug 1290194] Re: O.reset() does not free memory
Hi Anton, you are right, changing the script as follows has the same effect: # -*- coding: utf-8 import subprocess numberTests = 10 for z in range(numberTests): #O.reset() bodies= O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0)) print number of bodies:, len(O.bodies) for b in bodies: O.bodies.erase(b) cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0].strip() print Yade memory usage: , meminfo, kB cmd = egrep 'MemFree' /proc/meminfo process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0] print meminfo sys.exit(0) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1290194 Title: O.reset() does not free memory Status in Yet Another Dynamic Engine: New Bug description: O.reset() does not free the memory, i.e. if you run a series of simulations in a loop the memory usage is accumulating. Here is a script which reproduces the issue (it should affect all versions): # -*- coding: utf-8 import subprocess numberTests = 10 for z in range(numberTests): O.reset() O.bodies.append(pack.regularHexa(pack.inSphere((Vector3(0.0,0.0,0.0)),0.5),radius=0.01,gap=0)) print number of bodies:, len(O.bodies) cmd = ps -o vsz -p `pgrep yade` | grep -v VSZ process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0].strip() print Yade memory usage: , meminfo, kB cmd = egrep 'MemFree' /proc/meminfo process = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True) meminfo = process.communicate()[0] print meminfo sys.exit(0) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1290194/+subscriptions ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
