Page Comparison

E-mail from Frank:

Martijn and I have been looking at the rigid body rotations in MercuryDPM and especially the difference between how it is done for multispheres and other objects (including superquadratics).

This is my current understanding: inertia_ is the initial moment of inertia matrix, rotation of a particle are encoded using a quaternion. For multispheres there is a master-slave relation between particles. The center-of-mass motion and rotation of a multisphere are stored at the master particle.

For multispheres the angularAccelerateMaster method is used, while for other particles angularAccelerate is used. Both function should do the same, but for different types of particles.

angularAccelerateMaster seems fine to me (in principle), while angularAccelerate solves

 as 

Here I have used the subscript ‘lab’ to denote the laboratory frame of reference. It is related to the quantities in the frame of the ‘principal axis’ by a rotation, e.g. , where  is the moment of inertial matrix actually used in the code.

I think here a term is missing in the update performed by angularAccelerate! The (correct) equation of motion is

This is actually done in angularAccelerateMaster, but in the frame of the ‘principal axes’

I have a few remarks:

1. The update of the angular velocity by angularAccelerate seems to be missing a term. I am not sure how important the missing term is in practice.
2. angularAccelerateMaster uses principal directions. This seems to contain exactly the same information as the quaternion. I have the impression this is superfluous.
3. I think, when using a fixed reference frame for the moment of inertia matrix, it is best to actually choose the coordinate system formed by the principal axis of the moment of inertia. In that reference frame the moment of inertia is diagonal: .
4. My proposal for a streamlined unified implementation would be to use  and a quaternion,  (with ) for the rotation of the principle axes (initially directed in x, y and z directions) to the current orientation. The dynamics now becomes

Here  is in the principal axes frame of reference. For the quaternion we have, applying the quaternion algebra,   and  where vectors are treated as quaternions with zero scalar part. Note that the angular velocity in the principal axes frame of reference was used. Therefore the multiplication with the angular momentum vector is on the right ().

1. In the implementation I do not get the invInertia2_ variable. Is this really needed?
   
   

With kind regards,

Frank

•  Juan Esteban Alvarez Thomas Weinhart Anthony Thornton look at multisphere issues/selftests

Update: still to do

MultiSphere will be reimplemented

•  Anthony Thornton Juan cannot make branches; fix

Three build systems. How to merge together.

•  Anthony Thornton look at coupling branch.

Oomphlib Oomph-lib coupling works again; , using an external oomphlib oomph-lib directory and the vendor branch.

We will move from svn to git, using gitlab.utwente.nl

For everyone who is new to git or wants to know more about it: Git Course

Has no documentation, should be added

Next MercuryMonth.

Hassan needs force-controlled walls, not unit cells; will think about implementing it; control should be the same.

•  Thomas Weinhart to merge back feature into Trunk
  Not needed anymore. I (Timo) will use the Luding model.

Update: Reza is working on a independent controller that can be applied to anything (walls as well).

•  Anthony sends MercuryDPM book to Timo
•  Thomas adds Timo, Reza, Martijn

Use cmake or ccmake from the command line instead of the gui.

Workaround:

cmake -DCMAKE_PREFIX_PATH=/usr/local/Trolltech/Qt-4.8.7/<something-something>/lib/cmake/ ../myproject