# XML guide: definition of attributes of rigid objects

**XML guide**(version April 2019, section 2.6)?

These attributes can be computed by GenCase or be custom-defined in the code. In order to specify the values correctly, I would need to know more about their definitions.

The attribute

**center**is defined as the 'gravity center of the rigid object'.

- Q1: Is this the 'centre of mass'? I presume so, this is just about matching terminologies.
- Q2: Which reference system should the coordinates be given in? The global one (the domain, as from inside
**definition**) or the local one (the object, as from inside a**setmkbound**for example)? - Q3: Reformulation of Q2. Say that I draw an object after rotating the global reference system (
**rotate x=...**), and do not revert to the original system (no**matrixreset**) before moving on to the**floatings**specifications. Will the coordinates of "center" live in the original or in the modified reference system? - Q4: Linked to Q1. Does the code takes into account eccentricity when the centre of mass is not the centroid of the figure?

**inertia**is defined as 'momentum of inertia of the rigid object'. There is a slip of the pen since it should be 'moment of inertia'.

- Q5: With respect to which axes are these moments of inertia?
- Q6: Is the code informed about the principal moments of inertia of objects with a predefined shape such as
**drawbox**,**drawsphere**? - Q7: Similar to Q3. If the object I drew is no longer aligned with the global reference system, which axes are considered for the moments of inertia?

Thanks in advance for dealing with this.

## Comments

Q1: Is this the 'centre of mass'? I presume so, this is just about matching terminologies.YES

Q2: Which reference system should the coordinates be given in? The global one (the domain, as from inside definition) or the local one (the object, as from inside a setmkbound for example)?Global ones of course, however this is easy to test to get a faster response

Q3: Reformulation of Q2. Say that I draw an object after rotating the global reference system (rotate x=...), and do not revert to the original system (no matrixreset) before moving on to the floatings specifications. Will the coordinates of "center" live in the original or in the modified reference system?Response in https://dual.sphysics.org/vanilla/discussion/1631/centre-of-mass-of-eccentric-objects-rotated-with-rotateaxis#latest

Q4: Linked to Q1. Does the code takes into account eccentricity when the centre of mass is not the centroid of the figure?Not sure, let us check...

The attribute inertia is defined as 'momentum of inertia of the rigid object'. There is a slip of the pen since it should be 'moment of inertia'.Yes, we have to correct this. Thanks

Q5: With respect to which axes are these moments of inertia?X-axis, Y-axis and Z-axis

Q6: Is the code informed about the principal moments of inertia of objects with a predefined shape such as drawbox, drawsphere?No need, since we use the general formulation to compute any figure, so that you can check that results for a box, for example, will converge to theoretical value with accuracy.

Q7: Similar to Q3. If the object I drew is no longer aligned with the global reference system, which axes are considered for the moments of inertia?X-axis, Y-axis and Z-axis

Re

Q2, you have been fast enough to make it worth waiting :-)Re

Q5andQ7, thegivensfor one object I have are themoments of inertia with respect to the principal axes of inertia, which always have the centre of mass as origin.Do I then understand it well that the correct procedure to

inputthis object istheselatter moments as an attributes within ' floating'a) you can allow GenCase to compute the value according to the moment of inertia of a set of points with mass

b) you can define the values you know in the XML

however, after this time=0, the code will compute the rotations using that moment of inertia, not sure what you mean with "DualSPHysics calculate the moments of inertia wrt the global axes at each time step"?

From Q5/Q7 I understood that we impose the conservation of angular momentum with respect to the lattice/global axes at each time step. Logical.

If the moments of inertia are referred to the

principal axes of inertia, these are properties/attributes of the object and need not to be recomputed at each time step. However, as time goes by, the solver would need to convert these object attributes into the moments with respect of theglobal axes, based on the motion and rotation of the object, again to enforce the conservation of angular momentum around those global axes.If the moments of inertia are given relative to the global reference axes, and the object roams and rotates, the moments of inertia change at each time step. This because the distribution of masses with respect to those global axes has changed. And the code should take care of this. Now I understand that is the way DSPH works.

This was my (perhaps confused/confusing) thinking behind "DualSPHysics calculate the moments of inertia wrt the global axes at each time step". But this topic comes closer to the other companion post https://dual.sphysics.org/vanilla/discussion/1631/centre-of-mass-of-eccentric-objects-rotated-with-rotateaxis , so I will continue it there.

After some testing around, I felt I have to resume with this thread. Please refer to the cubes in the figure.

At the design stage, they have the same mass of 1kg, the edge length is 1m and let's suppose they have uniform density. Out of these properties, the principal axes of inertia are aligned with the edges and pass for the centre of mass, which is also the centre of the figure in this case of uniform density. The principal moments of inertia are also equal because of the object's symmetry. From the books I got that the value of the principal moments of inertia is (mL^2)/6=0.1667 kgm^2.

In the input stage, I am not setting these moments of inertia myself, but leave it to DualSPHysics to compute their values. I can set the properties of these objects as floatings in the input xml file (Case_Def.xml) and read the matrix of moments of inertia in the output xml file (Case.xml).

The

white cubeat the origin is the test case. I expect the inertia matrix to be [I 0 0; 0 I 0; 0 0 I] where I is a particle-based approximation of the moment of the inertia, a single value in this case. Thanks for the answer to Q6 for clarifying the approximate nature of the calculation. With the particle resolution I chose, I=0.2 kg/m^2 instead of 0.1667. I can indeed recognize that the computed value tends to the expected one with the reduced particle distance. So this 0.2 is OK. The computed inertia matrix is [0.2 0 0; 0 0.2 0; 0 0 0.2]. Take it as ground truth.Look now at the

blue cubes. They have been translated away from the origin without rotation. The inertia matrix from the output xml is again [0.2 0 0; 0 0.2 0; 0 0 0.2] forall cubes. Hence I conclude that the moments of inertia reported by DualSPHysics are thosewith respect to the principal axes of inertia, thus the local ones, in contrast with answer to Q5/Q6. If they were the moments of inertia with respect to the lattice reference system, some of all of the moments should have increased because of the greater distance between the object and the axes. Also we should have some cross-moments off the diagonal, for some axes are no longer axes of symmetry for the cubes.Let's look now at the

green cubes. They have been both translated and rotated by different angles, namely 30, 45, 75 around the vertical axis through the centre of mass. If the conclusion above still held --- that the moments of inertia are with respect to the principal axes of inertia ---, I should get the same inertia matrix [0.2 0 0; 0 0.2 0; 0 0 0.2]. This is not the case though. For example, the value for the light green cube is [0.28 0 0 ; 0 .28 0 ; 0 0.28 0].This then lead me to think that the moments of inertia are perhaps computed

with respect to a system of axes parallel to the lattice axis and passing through the centre of mass/figure. Then I would have expected either the same or different inertia matrices depending on different angles. However, they are the same for 30 and 45 degrees [0.28 0 0 ; 0 .28 0 ; 0 0.28 0], while for 75 degrees the matrix is [0.2 0 0; 0 0.2 0; 0 0 0.2], the same as the non-rotated cubes.Also, this situation holds even when I halve the interparticle distance. It might well be a presentational glitch. At this very moment I am not quite sure what I am looking at, and risks of great confusion follow. Beside possible flaws in my thinking, there is an evident lack of consistency in the results. I am available to send the input and output xml file if this is useful.

On the positive note, the calculation of the centres of mass is fine across these experiments.

Thanks for any advice and clarification.

Good point: "with respect to a system of axes parallel to the lattice axis and passing through the centre of mass/figure"

Then I was wrong in the responses I wrote in the other thread, sorry.

Perhaps @jmdalonso and @RCanelas can help here

Regards

Alex

Thanks Alex for the clarification.

Some additional information: I used interparticle distances of 0.1 and 0.05, and even with dx=0.01 I obtain results of the same sort.

I also thought that, if the moments of inertia are computed for a local system of axes parallel to the global ones and passing through the centre of mass, the inertia tensors of all cubes in the figure should be the same.

If I am not wrong, this should be so because, given a direction

rpassing from the centre of mass, the moment of inertia with respect to that directionIris given byIr = Ia cos² alpha + Ib cos² beta + Ic cos² gamma. There,a,b,care the principal axes of inertia; andalpha, beta, gammaare the direction cosines ofrwith respect to the axesa,b,c.In this case of cubes rotated around the

zaxis, thus on thexyplane, it holdscos beta = sin alpha, andcos gamma=0for any angle of rotation aroundz, sayalpha. Then, sinceIa=Ib=Ic=Ibecause of a cube's symmetry, it followsIr=Itoo. If that' s correct, this may help check the goodness of the results too.Hi

I have tested the GenCase for calculation of canter of mass and the inertia matrix.

I have defined a cube with the "massbody" of 60.

<drawbox>

<boxfill>solid</boxfill>

<point x="1.0" y="2.0" z="1.5" />

<size x="5" y="1.5" z="1.8" />

</drawbox>

The GenCase accurately computes the center of Mass, that is :

<center x="3.5" y="2.75" z="2.4" units_comment="metres (m)" />

By hand calculation, the inertia matrix is:

v11=Ixx=826.8 , v12=-Ixy=-577.5 , v13=-Ixz=-8.4

v21=Iyx=-577.5 , v2=Iyy=1221.8 , v23=-Iyz=-396

v31=Izx=-8.4 , v32=-Izy=-396 , v33=Izz=1325

But, the GenCase computes as follow:

<inertia units_comment="kg*m^2">

<values v11="29.1" v12="-2.42655e-16" v13="4.18149e-16" />

<values v21="-2.42655e-16" v22="144.6" v23="-9.34394e-17" />

<values v31="4.18149e-16" v32="-9.34394e-17" v33="139.5" />

</inertia>

What is wrong?

(The xml file is attached.)

I tried several times with a Box ... and results with GenCase are good

Try please with a rectangular box and compare with theoretical data

In the previous comment, a rectangular box is used.

You have not computed by hand in the proper way.....

Note that theoretically Izz=M(a^2+b^2)/12.... so that 136.25 kg/m^2

and Izz(GenCase)=139.5 not bad if using individual particles

I computed the inertia with respect to the xyz axis, and not to the center of the mass of the object.

So, we can conclude that the GenCase computes the inertia matrix with respect to the center of the mass of each object.

Since for solving the rotation motion of an object, how does the code deal with the inertia values with respect to the xyz axis?

The code computes motions and rotations respect to the center of the mass of each object.

You can see the source code in function RunFloating in JSphCpuSingle.cpp

To summarise the progress of this long thread:

originin the centre of mass of the object; 2. withaxesparallel to the global reference system, that of the lattice in fact;fullinertiaoffloatingin the xml file.Please @Alex check whether we are on the same page and correct, for benefit of future readers.

The open question of this thread is the following. The principal matrix of inertia of a cube is an isotropic tensor. The inertia matrix of a cube takes a single value with respect to

anyreference system passing from the centre of mass, regardless of how you rotate the cube. Computationally, though, for some rotations the moments of inertia of the same cube turn out to take different values, at the same particle resolution. I am aware that this issue is to be triaged in due course, so let's wait for confirmation/confutation.Thanks for the clarification!

What is the difference when we want to implement "Chrono"?

Regards

@amir It is a very valid question indeed. I would possibly open another thread, for future readers to find relevant answers to your question easily. Thanks for sharing your interest in this topic.

A quick question: are the moments of inertia calculated in single or double precision? If both, is there a possibility to control this choice? (At least I haven't found relevant options in the help of Gencase.) Thanks for helping out with this shortcut.

This topic seems to be very interesting and helpful. I have faced questions:

Consider we have an object which the center of mass is not coincident with the center of centroid (e.g. due to its non uniform density).

1- In the xml file, we should introduce its center of mass, not the centroid. Is it true?

2- The main question is about the inertia matrix:

Should the inertia matrix be calculated and imported about its center of mass or about centroid?

3- Consider an object with a nuifrom mass. The center of mass is equal to the centroid. The object is only allowed to rotate about an axis which does not pass the centroid (simulation is carried with the Chrono).

Should the inertia matrix be calculated and imported about its center of mass or about the rotation axis?

Cheers!

For future readers. The issues pointed out in this thread have been investigated further in this other post https://forums.dual.sphysics.org/discussion/1666/gencase-identical-floatings-have-different-number-of-particles I will share additional findings there.