[Yade-dev] Test needed from Clumps-users
Dear users/devs, who is working with clumps,
I have done a tiny modification in NewtonIntegrator [1], which
should fix numerical instability with clumps in a rare cases.
Subject: [PATCH] Do not use getTorqueUnsynced and forces.getForceUnsynced in
clumps
It seems both of these commands are unsafe. It causes NaN velocities
in a very specific cases. From my point of view it is OK, because
addForceTorqueFromMembers does not modify data itself.
---
pkg/dem/NewtonIntegrator.cpp | 6 --
1 file changed, 6 deletions(-)
diff --git a/pkg/dem/NewtonIntegrator.cpp b/pkg/dem/NewtonIntegrator.cpp
index e961bf2..082add8 100644
--- a/pkg/dem/NewtonIntegrator.cpp
+++ b/pkg/dem/NewtonIntegrator.cpp
@@ -146,14 +146,8 @@ void NewtonIntegrator::action()
// clumps forces
if(b-isClump()) {
b-shape-castClump().addForceTorqueFromMembers(state,scene,f,m);
- #ifdef YADE_OPENMP
- //it is safe here, since only one thread will read/write
- scene-forces.getTorqueUnsynced(id)+=m;
- scene-forces.getForceUnsynced(id)+=f;
- #else
scene-forces.addTorque(id,m);
scene-forces.addForce(id,f);
- #endif
}
//in most cases, the initial force on clumps will be zero and next
line is not changing f and m, but make sure we don't miss something
(e.g. user defined forces on clumps)
f=scene-forces.getForce(id); m=scene-forces.getTorque(id);
--
1.9.3
Please, test you scripts with the newest version. Yadedaily should
get this fix tonight.
Comments are very welcome.
[1]
https://github.com/yade/trunk/commit/5707bb55fb9a3605e10a82cdecbec8efcc7d906f
Best regards
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] Test needed from Clumps-users
Hi Anton,
Two problems I suspect:
1/ It needs speed benchmarking. This little change may have a huge
impact on parallel performance, because - if I don't miss something -
each addForce/addTorque trigger the synchronization of the whole
force/torque containers [1], which is not small thing as you can see.
If this is done for each clump it makes 3 nested loop O(N² x numThreads).
If it occures as I think, it should be visible in O.forces.syncCount.
Normally this value is equal to the number of timesteps.
2/ It is not thread-safe. addForce/addTorque are ok in interaction loop
because it is write-only. Here different threads will try to
write-synchronize-read at the same time.
Bruno
[1] https://github.com/yade/trunk/blob/master/core/ForceContainer.hpp#L128
On 16/05/14 11:48, Anton Gladky wrote:
Dear users/devs, who is working with clumps,
I have done a tiny modification in NewtonIntegrator [1], which
should fix numerical instability with clumps in a rare cases.
Subject: [PATCH] Do not use getTorqueUnsynced and forces.getForceUnsynced in
clumps
It seems both of these commands are unsafe. It causes NaN velocities
in a very specific cases. From my point of view it is OK, because
addForceTorqueFromMembers does not modify data itself.
---
pkg/dem/NewtonIntegrator.cpp | 6 --
1 file changed, 6 deletions(-)
diff --git a/pkg/dem/NewtonIntegrator.cpp b/pkg/dem/NewtonIntegrator.cpp
index e961bf2..082add8 100644
--- a/pkg/dem/NewtonIntegrator.cpp
+++ b/pkg/dem/NewtonIntegrator.cpp
@@ -146,14 +146,8 @@ void NewtonIntegrator::action()
// clumps forces
if(b-isClump()) {
b-shape-castClump().addForceTorqueFromMembers(state,scene,f,m);
- #ifdef YADE_OPENMP
- //it is safe here, since only one thread will read/write
- scene-forces.getTorqueUnsynced(id)+=m;
- scene-forces.getForceUnsynced(id)+=f;
- #else
scene-forces.addTorque(id,m);
scene-forces.addForce(id,f);
- #endif
}
//in most cases, the initial force on clumps will be zero and next
line is not changing f and m, but make sure we don't miss something
(e.g. user defined forces on clumps)
f=scene-forces.getForce(id); m=scene-forces.getTorque(id);
--
___
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
Re: [Yade-dev] Test needed from Clumps-users
Hi all,
sorry for the noise. This change is reverted.
Anton
2014-05-16 11:48 GMT+02:00 Anton Gladky gladky.an...@gmail.com:
Dear users/devs, who is working with clumps,
I have done a tiny modification in NewtonIntegrator [1], which
should fix numerical instability with clumps in a rare cases.
Subject: [PATCH] Do not use getTorqueUnsynced and forces.getForceUnsynced in
clumps
It seems both of these commands are unsafe. It causes NaN velocities
in a very specific cases. From my point of view it is OK, because
addForceTorqueFromMembers does not modify data itself.
---
pkg/dem/NewtonIntegrator.cpp | 6 --
1 file changed, 6 deletions(-)
diff --git a/pkg/dem/NewtonIntegrator.cpp b/pkg/dem/NewtonIntegrator.cpp
index e961bf2..082add8 100644
--- a/pkg/dem/NewtonIntegrator.cpp
+++ b/pkg/dem/NewtonIntegrator.cpp
@@ -146,14 +146,8 @@ void NewtonIntegrator::action()
// clumps forces
if(b-isClump()) {
b-shape-castClump().addForceTorqueFromMembers(state,scene,f,m);
- #ifdef YADE_OPENMP
- //it is safe here, since only one thread will read/write
- scene-forces.getTorqueUnsynced(id)+=m;
- scene-forces.getForceUnsynced(id)+=f;
- #else
scene-forces.addTorque(id,m);
scene-forces.addForce(id,f);
- #endif
}
//in most cases, the initial force on clumps will be zero and next
line is not changing f and m, but make sure we don't miss something
(e.g. user defined forces on clumps)
f=scene-forces.getForce(id); m=scene-forces.getTorque(id);
--
1.9.3
Please, test you scripts with the newest version. Yadedaily should
get this fix tonight.
Comments are very welcome.
[1]
https://github.com/yade/trunk/commit/5707bb55fb9a3605e10a82cdecbec8efcc7d906f
Best regards
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] [Bug 1318513] Re: utils.calm() calms only spheres and clumps
I left mask parameter for the purpose of slecting bodies to calm and modified documentation of the function (the original version mentioned, that the function calms all bodies, which was the source of my confusion). Thanks for discussion Jan 2014-05-12 12:06 GMT+02:00 Jan Stránský honzik.stran...@gmail.com: Ok, I will think about it and implement something in 2 weeks. If you wanted to do something earlier, feel free to modify it. cheers Jan 2014-05-12 11:30 GMT+02:00 Anton Gladky 1318...@bugs.launchpad.net: Well, we have mask-parameter there, which is also relatively flexible. But includeList is also a good idea and will probably be even faster. Anton 2014-05-12 11:18 GMT+02:00 Christian Jakob 1318...@bugs.launchpad.net: Hi, I implemented calm() and used it as alternative damping method (e.g. when using a small local damping in a sim.). From this discussion I can see, that an update is needed for this method. An easy way could be to introduce an includeBodyList (or an excludeBodyList). example: includeList = [] for b in O.bodies: if CONDITION: includeList.append(b.id) calm(includeList) -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1318513 Title: utils.calm() calms only spheres and clumps Status in Yet Another Dynamic Engine: New Bug description: Fix is very easy, I just wanted to know opinion of other devs (e.g. if there is a reason I missed) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1318513/+subscriptions ** Changed in: yade Status: New = Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1318513 Title: utils.calm() calms only spheres and clumps Status in Yet Another Dynamic Engine: Fix Released Bug description: Fix is very easy, I just wanted to know opinion of other devs (e.g. if there is a reason I missed) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1318513/+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] [Branch ~yade-pkg/yade/git-trunk] Rev 3958: modification of utils.calm function (bug 1318513)
revno: 3958
committer: Jan Stransky jan.stran...@fsv.cvut.cz
timestamp: Fri 2014-05-16 14:22:07 +0200
message:
modification of utils.calm function (bug 1318513)
modified:
pkg/dem/Shop_02.cpp
py/_utils.cpp
--
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
=== modified file 'pkg/dem/Shop_02.cpp'
--- pkg/dem/Shop_02.cpp 2014-04-02 15:34:57 +
+++ pkg/dem/Shop_02.cpp 2014-05-16 12:22:07 +
@@ -427,12 +427,9 @@
FOREACH(shared_ptrBody b, *scene-bodies){
if (!b || !b-isDynamic()) continue;
if(((mask0) and ((b-groupMask mask)==0))) continue;
- Sphere* s=dynamic_castSphere*(b-shape.get());
- if ( (s) or ( (!s) (b-isClump()) ) ){
- b-state-vel=Vector3r::Zero();
- b-state-angVel=Vector3r::Zero();
- b-state-angMom=Vector3r::Zero();
- }
+ b-state-vel=Vector3r::Zero();
+ b-state-angVel=Vector3r::Zero();
+ b-state-angMom=Vector3r::Zero();
}
}
=== modified file 'py/_utils.cpp'
--- py/_utils.cpp 2014-04-15 16:49:07 +
+++ py/_utils.cpp 2014-05-16 12:22:07 +
@@ -542,7 +542,7 @@
py::def(getBodyIdsContacts,Shop__getBodyIdsContacts,(py::args(bodyID)=0),Get a list of body-ids, which contacts the given body.);
py::def(maxOverlapRatio,maxOverlapRatio,Return maximum overlap ration in interactions (with :yref:`ScGeom`) of two :yref:`spheresSphere`. The ratio is computed as $\\frac{u_N}{2(r_1 r_2)/r_1+r_2}$, where $u_N$ is the current overlap distance and $r_1$, $r_2$ are radii of the two spheres in contact.);
py::def(shiftBodies,shiftBodies,(py::arg(ids),py::arg(shift)),Shifts bodies listed in ids without updating their velocities.);
- py::def(calm,Shop__calm,(py::arg(mask)=-1),Set translational and rotational velocities of all bodies to zero.);
+ py::def(calm,Shop__calm,(py::arg(mask)=-1),Set translational and rotational velocities of bodies to zero. Applied to all bodies by default. To calm only some bodies, use mask parameter, it will calm only bodies with groupMask compatible to given value);
py::def(setNewVerticesOfFacet,setNewVerticesOfFacet,(py::arg(b),py::arg(v1),py::arg(v2),py::arg(v3)),Sets new vertices (in global coordinates) to given facet.);
py::def(setContactFriction,Shop::setContactFriction,py::arg(angleRad),Modify the friction angle (in radians) inside the material classes and existing contacts. The friction for non-dynamic bodies is not modified.);
py::def(growParticles,Shop::growParticles,(py::args(multiplier), py::args(updateMass)=true, py::args(dynamicOnly)=true, py::args(discretization)=0), Change the size of spheres and sphere clumps by the multiplier. If updateMass=True, then the mass is updated. dynamicOnly=True is mandatory in many cases since in current implementation the function would crash on the non-spherical and non-dynamic bodies (e.g. facets, boxes, etc.). For clumps the masses and inertias are adapted automatically when discretization0 (for details of inertia tensor integration scheme see :yref:`clump()BodyContainer.clump`).);
___
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] [Branch ~yade-pkg/yade/git-trunk] Rev 3956: Revert last change in Newtonintegrator.
revno: 3956 committer: Anton Gladky gladky.an...@gmail.com timestamp: Fri 2014-05-16 13:48:12 +0200 message: Revert last change in Newtonintegrator. modified: pkg/dem/NewtonIntegrator.cpp -- 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 === modified file 'pkg/dem/NewtonIntegrator.cpp' --- pkg/dem/NewtonIntegrator.cpp 2014-05-16 09:46:02 + +++ pkg/dem/NewtonIntegrator.cpp 2014-05-16 11:48:12 + @@ -148,6 +148,14 @@ b-shape-castClump().addForceTorqueFromMembers(state,scene,f,m); scene-forces.addTorque(id,m); scene-forces.addForce(id,f); +#ifdef YADE_OPENMP +//it is safe here, since only one thread will read/write +scene-forces.getTorqueUnsynced(id)=m; +scene-forces.getForceUnsynced(id)=f; +#else +scene-forces.addTorque(id,m); +scene-forces.addForce(id,f); +#endif } //in most cases, the initial force on clumps will be zero and next line is not changing f and m, but make sure we don't miss something (e.g. user defined forces on clumps) f=scene-forces.getForce(id); m=scene-forces.getTorque(id); ___ 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] [Branch ~yade-pkg/yade/git-trunk] Rev 3955: Make addForceTorqueFromMembers more readable.
revno: 3955
committer: Anton Gladky gladky.an...@gmail.com
timestamp: Fri 2014-05-16 11:46:02 +0200
message:
Make addForceTorqueFromMembers more readable.
modified:
core/Clump.cpp
--
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
=== modified file 'core/Clump.cpp'
--- core/Clump.cpp 2014-03-15 15:30:36 +
+++ core/Clump.cpp 2014-05-16 09:46:02 +
@@ -55,8 +55,12 @@
void Clump::addForceTorqueFromMembers(const State* clumpState, Scene* scene, Vector3r F, Vector3r T){
FOREACH(const MemberMap::value_type mm, members){
- const Body::id_t memberId=mm.first; const shared_ptrBody member=Body::byId(memberId,scene); assert(member-isClumpMember()); State* memberState=member-state.get();
- const Vector3r f=scene-forces.getForce(memberId); const Vector3r t=scene-forces.getTorque(memberId);
+ const Body::id_t memberId=mm.first;
+ const shared_ptrBody member=Body::byId(memberId,scene);
+ assert(member-isClumpMember());
+ State* memberState=member-state.get();
+ const Vector3r f=scene-forces.getForce(memberId);
+ const Vector3r t=scene-forces.getTorque(memberId);
F+=f;
T+=t+(memberState-pos-clumpState-pos).cross(f);
}
___
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] [Branch ~yade-pkg/yade/git-trunk] Rev 3954: Do not use getTorqueUnsynced and forces.getForceUnsynced in clumps
revno: 3954
committer: Anton Gladky gladky.an...@gmail.com
timestamp: Fri 2014-05-16 11:46:02 +0200
message:
Do not use getTorqueUnsynced and forces.getForceUnsynced in clumps
It seems both of these commands are unsafe. It causes NaN velocities
in a very specific cases. From my point of view it is OK, because
addForceTorqueFromMembers does not modify data itself.
modified:
pkg/dem/NewtonIntegrator.cpp
--
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
=== modified file 'pkg/dem/NewtonIntegrator.cpp'
--- pkg/dem/NewtonIntegrator.cpp 2014-05-15 14:47:33 +
+++ pkg/dem/NewtonIntegrator.cpp 2014-05-16 09:46:02 +
@@ -146,14 +146,8 @@
// clumps forces
if(b-isClump()) {
b-shape-castClump().addForceTorqueFromMembers(state,scene,f,m);
-#ifdef YADE_OPENMP
-//it is safe here, since only one thread will read/write
-scene-forces.getTorqueUnsynced(id)+=m;
-scene-forces.getForceUnsynced(id)+=f;
-#else
scene-forces.addTorque(id,m);
scene-forces.addForce(id,f);
-#endif
}
//in most cases, the initial force on clumps will be zero and next line is not changing f and m, but make sure we don't miss something (e.g. user defined forces on clumps)
f=scene-forces.getForce(id); m=scene-forces.getTorque(id);
___
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] [Branch ~yade-pkg/yade/git-trunk] Rev 3957: Polyhedra implementation improvement (Contributed by Jan Elias)
revno: 3957
committer: Jan Stransky jan.stran...@fsv.cvut.cz
timestamp: Fri 2014-05-16 13:58:59 +0200
message:
Polyhedra implementation improvement (Contributed by Jan Elias)
modified:
pkg/dem/Polyhedra.cpp
pkg/dem/Polyhedra.hpp
pkg/dem/Polyhedra_Ig2.cpp
pkg/dem/Polyhedra_splitter.cpp
pkg/dem/Polyhedra_support.cpp
py/_polyhedra_utils.cpp
py/polyhedra_utils.py
--
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
=== modified file 'pkg/dem/Polyhedra.cpp'
--- pkg/dem/Polyhedra.cpp 2013-10-17 11:59:10 +
+++ pkg/dem/Polyhedra.cpp 2014-05-16 11:58:59 +
@@ -16,7 +16,7 @@
YADE_PLUGIN(/* self-contained in hpp: */ (Polyhedra) (PolyhedraGeom) (Bo1_Polyhedra_Aabb) (PolyhedraPhys) (PolyhedraMat) (Ip2_PolyhedraMat_PolyhedraMat_PolyhedraPhys) (PolyhedraVolumetricLaw)
/* some code in cpp (this file): */
#ifdef YADE_OPENGL
- (Gl1_Polyhedra)
+ (Gl1_Polyhedra) (Gl1_PolyhedraGeom) (Gl1_PolyhedraPhys)
#endif
);
@@ -197,9 +197,9 @@
Triangulation dt(nuclei.begin(), nuclei.end());
Triangulation::Vertex_handle zero_point = dt.insert(CGALpoint(5.,5.,5.));
v.clear();
-std::vectorTriangulation::Cell_handle ch_cells;
+std::vectortypename Triangulation::Cell_handle ch_cells;
dt.incident_cells(zero_point,std::back_inserter(ch_cells));
- for(std::vectorTriangulation::Cell_handle::iterator ci = ch_cells.begin(); ci !=ch_cells.end(); ++ci){
+ for(std::vectortypename Triangulation::Cell_handle::iterator ci = ch_cells.begin(); ci !=ch_cells.end(); ++ci){
v.push_back(FromCGALPoint(dt.dual(*ci))-Vector3r(5.,5.,5.));
}
@@ -256,14 +256,15 @@
#ifdef YADE_OPENGL
#includeyade/lib/opengl/OpenGLWrapper.hpp
- void Gl1_Polyhedra::go(const shared_ptrShape cm, const shared_ptrState,bool,const GLViewInfo)
+ bool Gl1_Polyhedra::wire;
+ void Gl1_Polyhedra::go(const shared_ptrShape cm, const shared_ptrState,bool wire2,const GLViewInfo)
{
glMaterialv(GL_FRONT,GL_AMBIENT_AND_DIFFUSE,Vector3r(cm-color[0],cm-color[1],cm-color[2]));
glColor3v(cm-color);
Polyhedra* t=static_castPolyhedra*(cm.get());
vectorint faceTri = t-GetSurfaceTriangulation();
- if (0) {
+ if (wire || wire2) {
glDisable(GL_LIGHTING);
glBegin(GL_LINES);
#define __ONEWIRE(a,b) glVertex3v(t-v[a]);glVertex3v(t-v[b])
@@ -283,6 +284,58 @@
glEnd();
}
}
+
+
+ void Gl1_PolyhedraGeom::go(const shared_ptrIGeom ig, const shared_ptrInteraction, const shared_ptrBody, const shared_ptrBody, bool){ draw(ig);}
+
+ void Gl1_PolyhedraGeom::draw(const shared_ptrIGeom ig){
+ };
+
+ GLUquadric* Gl1_PolyhedraPhys::gluQuadric=NULL;
+ Real Gl1_PolyhedraPhys::maxFn;
+ Real Gl1_PolyhedraPhys::refRadius;
+ Real Gl1_PolyhedraPhys::maxRadius;
+ int Gl1_PolyhedraPhys::signFilter;
+ int Gl1_PolyhedraPhys::slices;
+ int Gl1_PolyhedraPhys::stacks;
+
+ void Gl1_PolyhedraPhys::go(const shared_ptrIPhys ip, const shared_ptrInteraction i, const shared_ptrBody b1, const shared_ptrBody b2, bool wireFrame){
+ if(!gluQuadric){ gluQuadric=gluNewQuadric(); if(!gluQuadric) throw runtime_error(Gl1_PolyhedraPhys::go unable to allocate new GLUquadric object (out of memory?).); }
+ PolyhedraPhys* np=static_castPolyhedraPhys*(ip.get());
+ shared_ptrIGeom ig(i-geom); if(!ig) return; // changed meanwhile?
+ PolyhedraGeom* geom=YADE_CASTPolyhedraGeom*(ig.get());
+ Real fnNorm=np-normalForce.dot(geom-normal);
+ if((signFilter0 fnNorm0) || (signFilter0 fnNorm0)) return;
+ int fnSign=fnNorm0?1:-1;
+ fnNorm=abs(fnNorm);
+ Real radiusScale=1.;
+ maxFn=max(fnNorm,maxFn);
+ Real realMaxRadius;
+ if(maxRadius0){
+ refRadius=min(0.03,refRadius);
+ realMaxRadius=refRadius;
+ }
+ else realMaxRadius=maxRadius;
+ Real radius=radiusScale*realMaxRadius*(fnNorm/maxFn);
+ if (radius=0.) radius = 1E-8;
+ Vector3r color=Shop::scalarOnColorScale(fnNorm*fnSign,-maxFn,maxFn);
+
+ Vector3r p1=b1-state-pos, p2=b2-state-pos;
+ Vector3r relPos;
+ relPos=p2-p1;
+ Real dist=relPos.norm();
+
+ glDisable(GL_CULL_FACE);
+ glPushMatrix();
+ glTranslatef(p1[0],p1[1],p1[2]);
+ Quaternionr q(Quaternionr().setFromTwoVectors(Vector3r(0,0,1),relPos/dist /* normalized */));
+ // using Transform with OpenGL: http://eigen.tuxfamily.org/dox/TutorialGeometry.html
+ //glMultMatrixd(Eigen::Affine3d(q).data());
+ glMultMatrix(Eigen::TransformReal,3,Eigen::Affine(q).data());
+ glColor3v(color);
+ gluCylinder(gluQuadric,radius,radius,dist,slices,stacks);
+ glPopMatrix();
+ }
#endif
//**
@@ -362,9 +415,9 @@
// Apply forces on polyhedrons in collision based on geometric configuration
void PolyhedraVolumetricLaw::go(shared_ptrIGeom ig, shared_ptrIPhys ip, Interaction* I){
- if (!I-geom)
Re: [Yade-dev] [Branch ~yade-pkg/yade/git-trunk] Rev 3954: Do not use getTorqueUnsynced and forces.getForceUnsynced in clumps
Did you change your mind Anton? Or git-mistake? :) B On 16/05/14 14:38, nore...@launchpad.net wrote: revno: 3954 committer: Anton Gladky gladky.an...@gmail.com timestamp: Fri 2014-05-16 11:46:02 +0200 message: Do not use getTorqueUnsynced and forces.getForceUnsynced in clumps It seems both of these commands are unsafe. It causes NaN velocities in a very specific cases. From my point of view it is OK, because addForceTorqueFromMembers does not modify data itself. modified: pkg/dem/NewtonIntegrator.cpp -- 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 ___ 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 3954: Do not use getTorqueUnsynced and forces.getForceUnsynced in clumps
2014-05-16 14:56 GMT+02:00 Bruno Chareyre bruno.chare...@hmg.inpg.fr: Did you change your mind Anton? Or git-mistake? :) I tested wrong binary, which worked fine (clang, without OpenMP). OpenMP+GCC throws obviously runtime_error ForceContainer not thread-synchronized; call sync() first!. Thanks for your feedback anyway! 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] [Branch ~yade-pkg/yade/git-trunk] Rev 3954: Do not use getTorqueUnsynced and forces.getForceUnsynced in clumps
Did you change your mind Anton? Or git-mistake? :) Sorry for this message, I had the impression that you introduced the change again in rev3954 after reverting it. Just a weird sequence of emails maybe, on github it looks ok. Good to know that compilation with openMP also showed the problem. Cheers. 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
[Yade-dev] [Bug 1314736] Re: Segfault possibly in new parallel collider
I pushed a fix (3b09fb5) but I could not test it. Can you confirm? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1314736 Title: Segfault possibly in new parallel collider Status in Yet Another Dynamic Engine: New Bug description: I have got segfault, which is probably due to a new parallel collider. It happened on my local version, which is not yet merged to the main branch [1] (with ENABLE_LIQCONTROL=ON option), but it is unlikely due to my changes. Before the crash I have got the following warning several times: ERROR /home/gladk/dem/yade/trunk/pkg/common/InsertionSortCollider.cpp:132 insertionSortParallel: parallel sort not guaranteed to succeed; in chunk 1 of 2, bound descending past half-chunk. Consider turning ompThreads=1 for thread safety. Segmentation fault I will try to provide the minimal script, which produces such segfault. Bruno, maybe you have an idea, where it crashes? [1] https://github.com/gladk/trunk Thanks Anton To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1314736/+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] [Branch ~yade-pkg/yade/git-trunk] Rev 3961: remove typenames from Polyhedra.cpp (fixes compiler error)
revno: 3961
committer: Christian Jakob ja...@ifgt.tu-freiberg.de
timestamp: Fri 2014-05-16 17:26:12 +0200
message:
remove typenames from Polyhedra.cpp (fixes compiler error)
modified:
pkg/dem/Polyhedra.cpp
--
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
=== modified file 'pkg/dem/Polyhedra.cpp'
--- pkg/dem/Polyhedra.cpp 2014-05-16 11:58:59 +
+++ pkg/dem/Polyhedra.cpp 2014-05-16 15:26:12 +
@@ -197,9 +197,9 @@
Triangulation dt(nuclei.begin(), nuclei.end());
Triangulation::Vertex_handle zero_point = dt.insert(CGALpoint(5.,5.,5.));
v.clear();
-std::vectortypename Triangulation::Cell_handle ch_cells;
+std::vectorTriangulation::Cell_handle ch_cells;
dt.incident_cells(zero_point,std::back_inserter(ch_cells));
- for(std::vectortypename Triangulation::Cell_handle::iterator ci = ch_cells.begin(); ci !=ch_cells.end(); ++ci){
+ for(std::vectorTriangulation::Cell_handle::iterator ci = ch_cells.begin(); ci !=ch_cells.end(); ++ci){
v.push_back(FromCGALPoint(dt.dual(*ci))-Vector3r(5.,5.,5.));
}
___
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] [Branch ~yade-pkg/yade/git-trunk] Rev 3963: fix some indents
revno: 3963 committer: Christian Jakob ja...@ifgt.tu-freiberg.de timestamp: Fri 2014-05-16 19:03:55 +0200 message: fix some indents modified: py/wrapper/yadeWrapper.cpp -- 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 === modified file 'py/wrapper/yadeWrapper.cpp' --- py/wrapper/yadeWrapper.cpp 2014-05-15 17:50:26 + +++ py/wrapper/yadeWrapper.cpp 2014-05-16 17:03:55 + @@ -380,9 +380,9 @@ idsTmp[jj] = newSphere-id; } //cout thread omp_get_thread_num() unsets locker endl; - #ifdef YADE_OPENMP +#ifdef YADE_OPENMP omp_unset_lock(locker);//end of critical section -#endif +#endif Body::id_t newClumpId = clump(idsTmp, discretization); ret.append(python::make_tuple(newClumpId,idsTmp)); erase(b-id,false); ___ 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] [Branch ~yade-pkg/yade/git-trunk] Rev 3960: switch to 1-thread colliding when problem detected in parallel run (fix https://bugs.launchpad.ne...
revno: 3960
committer: Bruno Chareyre bruno.chare...@hmg.inpg.fr
timestamp: Fri 2014-05-16 16:41:07 +0200
message:
switch to 1-thread colliding when problem detected in parallel run (fix
https://bugs.launchpad.net/yade/+bug/1314736)
modified:
pkg/common/InsertionSortCollider.cpp
--
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
=== modified file 'pkg/common/InsertionSortCollider.cpp'
--- pkg/common/InsertionSortCollider.cpp 2014-05-06 15:32:52 +
+++ pkg/common/InsertionSortCollider.cpp 2014-05-16 14:41:07 +
@@ -109,8 +109,9 @@
}
///In the second sort, the chunks are connected consistently.
- ///If sorting requires to move a bound past half-chunk, the algorithm is not thread safe, if it happens we error out.
- ///Better than computing with messed up interactions
+ ///If sorting requires to move a bound past half-chunk, the algorithm is not thread safe,
+ /// if it happens we roll-back and run the 1-thread sort + send warning
+ bool parallelFailed=false;
#pragma omp parallel for schedule(dynamic,1) num_threads(ompThreads0 ? min(ompThreads,omp_get_max_threads()) : omp_get_max_threads())
for (unsigned k=1; knChunks;k++) {
@@ -130,12 +131,20 @@
j--;
}
v[j+1]=viInit;
- if (j=long(chunks[k]-chunkSize*0.5)) LOG_ERROR(parallel sort not guaranteed to succeed; in chunk k of nChunks , bound descending past half-chunk. Consider turning ompThreads=1 for thread safety.);
+ if (j=long(chunks[k]-chunkSize*0.5)) {
+LOG_WARN(parallel sort not guaranteed to succeed; in chunk k of nChunks , bound descending past half-chunk. Parallel colliding aborted, starting again in single thread. Consider turning ompThreads=1 for not wasting CPU time.);
+parallelFailed=true;}
}
- if (i=long(chunks[k]+chunkSize*0.5)) LOG_ERROR(parallel sort not guaranteed to succeed; in chunk k+1 of nChunks , bound advancing past half-chunk. Consider turning ompThreads=1 for thread safety.)
+ if (i=long(chunks[k]+chunkSize*0.5)) {
+ LOG_ERROR(parallel sort not guaranteed to succeed; in chunk k+1 of nChunks , bound advancing past half-chunk. Consider turning ompThreads=1 for not wasting CPU time.);
+ parallelFailed=true;}
}
/// Check again, just to be sure...
- for (unsigned k=1; knChunks;k++) if (v[chunks[k]]v[chunks[k]-1]) LOG_ERROR(parallel sort failed, consider turning ompThreads=1);
+ for (unsigned k=1; knChunks;k++) if (v[chunks[k]]v[chunks[k]-1]) {
+ LOG_ERROR(Parallel colliding failed, starting again in single thread. Consider turning ompThreads=1 for not wasting CPU time.);
+ parallelFailed=true;}
+
+ if (parallelFailed) return insertionSort(v,interactions, scene, doCollide);
/// Now insert interactions sequentially
for (int n=0;nompThreads;n++) for (size_t k=0, kend=newInteractions[n].size();kkend;k++) if (!interactions-found(newInteractions[n][k].first,newInteractions[n][k].second)) interactions-insert(shared_ptrInteraction(new Interaction(newInteractions[n][k].first,newInteractions[n][k].second)));
___
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
