Converting motion to axis-angle for lliggghts

Submitted by pfalkingham on Fri, 11/28/2014 - 13:24

Does anyone have any good methods for moving from euler rotations in x,y,and z worldspace, to the axis-angle format needed by liggghts? The method I've been using isn't as robust as I'd like.

Cheers.

pfalkingham | Mon, 01/12/2015 - 16:13

I think I'm running into issues again - I'm getting w, x, y, and z, but I'm not sure how to convert w into the period required by liggghts.... (my meshes are rotating by far less than they should be now)

richti83's picture

richti83 | Mon, 01/12/2015 - 19:27

When you allready have a valid quaternion, why wont you feed it directly to

mesh_->rotate(Q,dq,r);

where Q=[qw,qx,qy,qz] and dq=[1,0,0,0] ?

Don't forget to set the correct mesh velocity:

//move triangles ..
double dq[4]={1,0,0,0}; //dummy
double dr[3]={0,0,0};
mesh_->move(r,dr);
mesh_->rotate(Q,dq,r);
vectorZeroize3D(node);
vectorZeroize3D(rPA);
for(int i = 0; i < size; i++)
{
for(int iNode = 0; iNode < numNodes; iNode++)
{
vectorCopy3D(nodes[i][iNode],node); //copy r_local to node
vectorSubtract3D(node,r,rPA);
vectorCross3D(omega,rPA,v_node[i][iNode]); //w_0 x r_0 = v_0_rot
vectorAdd3D(v_node[i][iNode],v,v_node[i][iNode]); //v=v_rot_0 +v_trans_0
} //iNode
} //iMesh

What is your final aim to do this ?

Best,
Christian.

I'm not an associate of DCS GmbH and not a core developer of LIGGGHTS®
ResearchGate | Contact

pfalkingham | Mon, 01/12/2015 - 23:33

Hmmm... that seems a bit beyond what I'm hoping for. I have an animation in maya, and can export worldspace x, y, and z rotations :

tx, ty, tz, rx, ry, rz
0,0,0,0,0,0,
0,0,0,0,4.985422741,0,
0,0,0,0,17.84256419,0,
0,0,0,0,35.42274052,0,
0,0,0,0,54.57725441,0,
0,0,0,0,72.15743159,0,
0,0,0,0,85.01457304,0,
0,0,0,0,90,0,
0,0,0,3.86718552,86.13281448,0,
0,0,0,14.06249321,75.93750679,0,
0,0,0,28.47656109,61.52343891,0,
0,0,0,44.99999397,45.00000603,0,
0,0,0,61.52343891,28.47656109,0,
0,0,0,75.93748868,14.06251132,0,
0,0,0,86.1328092,3.8671908,0,
0,0,0,90,0,0,
0,0,0,86.1328191,0,3.867180899,
0,0,0,75.93750453,0,14.06249547,
0,0,0,61.52343467,0,28.47656533,
0,0,0,45.00001207,0,44.99998793,
0,0,0,28.47656533,0,61.52343467,
0,0,0,14.06249547,0,75.93750453,
0,0,0,3.86719146,0,86.13280854,
0,0,0,0,0,90,

This takes a cylinder lying on the origin pointing +ve X-axis, rotates it about y (to point down), then long axis rotates and returns, then rotates again. I'm struggling to convert this into some useable form within a liggghts script.

The way I used to do it was to take a point each end of a cylinder and calculate the vector from those, but I was concerned with losing long-axis rotation so ended up trying something new.

I tried converting these (subtracting the previous frame to get the motion per frame) to axis-angle, but couldn't get it to work regardless of rotation order. I've since tried applying each rotation, x, y, and z separately and trying to superimpose them as per the liggghts manual, but that doesn't seem to work - same confusions as when I tried axis-angle. Sorry, not being as specific as I'd like... frazzled after a day tinkering with angles.

pfalkingham | Tue, 01/13/2015 - 07:06

Ugh, it took posting that and sleeping on it to realise that it's not my conversion that's the problem, it's trying to make the motions in such small increments (sadly a necessity) - the axis of long-axis rotation at timestep 1, isn't the same axis at timestep 2. Back to the drawing board.

richti83's picture

richti83 | Tue, 01/13/2015 - 08:20

Good Morning,

I was struggeling with this problem 2 year ago when I started to couple a machine model of a wheel loader with LIGGGHTS (see YouTube Video).
The first problem I see is, that you have distance units and all liggghts move commands only accept velocity units.
To avoid this I've written a new mesh_mover method which get's the 3x3 rotation matrix T and a translation vector r and than applies this to every node of the mesh.
For that I've written a new move method in multi_node_mesh_I which is called from this custom mesh_mover method (=new move style)

template
void MultiNodeMesh::move(double *r, double **T)
{
if(!isTranslating())
this->error->all(FLERR,"Illegal call, need to register movement first");
int n = sizeLocal() + sizeGhost(); //apply movement only on mesh-points this proc ownes
for(int i = 0; i < n; i++)
{
vectorZeroize3D(center_(i));
for(int j = 0; j < NUM_NODES; j++)
{
vectorMatrixTrans(node_orig(i)[j],T,node_(i)[j]); //rotate
vectorAdd3D(node_(i)[j],r,node_(i)[j]); //add r_0 to points in local frame
vectorAdd3D(node_(i)[j],center_(i),center_(i)); //calc center
}
vectorScalarDiv3D(center_(i),static_cast(NUM_NODES));
}
updateGlobalBoundingBox();
}

The problem with this method is, that I need the translational and angular velocity of the moved body as input, because in the contact model you need the relative velocity between mesh and particle, otherwise the behaviour is crappy.

So before we start to share some Ideas I have three questions:
1.) can you get the velocities too ? (maybe by differentiate by t between two positions) or as direct output from maya ?
2.) are you afraid to add some lines of code to your local liggghts installation ?
3.) Do you think we can find any funding for a collaboration project ?

I think this would be a wonderful showcase for a coupled Multibody-DEM simulation, I've seen some of your videos at G+ and can imagine what you are trying to do. I can create a "machine model" of the gear mechanism of dead-animal-legs and feed this to liggghts.

Best,
Christian.

I'm not an associate of DCS GmbH and not a core developer of LIGGGHTS®
ResearchGate | Contact

pfalkingham | Tue, 01/13/2015 - 12:25

Hmmm... I was thinking about keeping track of local axes in my liggghts generation script, and using that to define axis-angle motions. i.e. at each time step calculate the new local axes based on the previous position and the amount of rotation.

In answer to your questions:
1) yes, but as you say only by outputting displacements/rotations per known time unit
2) terrified... but willing ;)
3) Not sure. Let me have a look around.

Peter.