# Gencase: identical floatings have different number of particles

I created 3 identical cubes as floatings with this code:

<geometry> ... <commands> <mainlist> <setshapemode>dp|real|bound</setshapemode> <setdrawmodemode="full"/> <setmkboundmk="10"comment="reference,centredinframeorigin"/> <drawbox> <boxfill>solid</boxfill> <pointx="-0.5"y="-0.5"z="-0.5"/> <sizex="1"y="1"z="1"/> </drawbox> <shapeoutfile="10"reset="true"/> <setmkboundmk="30"comment=""/> <drawbox> <boxfill>solid</boxfill> <pointx="2.5"y="-0.5"z="1.5"/> <sizex="1"y="1"z="1"/> </drawbox> <shapeoutfile="30"reset="true"/> <setmkboundmk="31"comment=""/> <drawbox> <boxfill>solid</boxfill> <pointx="1.0"y="0.0"z="1.5"/> <sizex="1"y="1"z="1"/> </drawbox> <shapeoutfile="31"reset="true"/> </mainlist> </commands> </geometry> <floatings> <floatingmkbound="10"><massbodyvalue="1"/></floating> <floatingmkbound="30"><massbodyvalue="1"/></floating> <floatingmkbound="31"><massbodyvalue="1"/></floating> </floatings>

They look like this:

For **dp=0.125** the properties of the first floating are

<floatingmkbound="10"mk="31"begin="0"count="1458"> <massbodyvalue="1"units_comment="kg"/> <masspartvalue="0.000685871"units_comment="kg"/> <centerx="0"y="0"z="0"units_comment="metres(m)"/> <inertiax="0.208333"y="0.208333"z="0.208333"units_comment="kg*m^2"/> </floating>

likewise for the others beside the centre of mass. Source: gencase xml output.

For **dp=0.12** there are differences *among the objects*:

<floatingmkbound="10"mk="31"begin="0"count="1458"> <massbodyvalue="1"units_comment="kg"/> <masspartvalue="0.000685871"units_comment="kg"/> <centerx="-0.02"y="-0.02"z="-0.02"units_comment="metres(m)"/> <inertiaunits_comment="kg*m^2"> <valuesv11="0.192"v12="2.16257e-17"v13="-9.51837e-19"/> <valuesv21="2.16257e-17"v22="0.192"v23="2.28441e-19"/> <valuesv31="-9.51837e-19"v32="2.28441e-19"v33="0.192"/> -- <floatingmkbound="30"mk="51"begin="1458"count="1458"> <massbodyvalue="1"units_comment="kg"/> <masspartvalue="0.000685871"units_comment="kg"/> <centerx="2.98"y="-0.02"z="2.02"units_comment="metres(m)"/> <inertiaunits_comment="kg*m^2"> <valuesv11="0.192"v12="-2.82505e-17"v13="7.99543e-19"/> <valuesv21="-2.82505e-17"v22="0.192"v23="3.80735e-20"/> <valuesv31="7.99543e-19"v32="3.80735e-20"v33="0.192"/> -- <floatingmkbound="31"mk="52"begin="2916"count="1620"> <massbodyvalue="1"units_comment="kg"/> <masspartvalue="0.000617284"units_comment="kg"/> <centerx="1.54"y="0.52"z="2.02"units_comment="metres(m)"/> <inertiaunits_comment="kg*m^2"> <valuesv11="0.2148"v12="1.00057e-17"v13="-1.13078e-18"/> <valuesv21="1.00057e-17"v22="0.192"v23="-2.53569e-18"/> <valuesv31="-1.13078e-18"v32="-2.53569e-18"v33="0.2148"/>

Do you spot mistakes/pitfalls? is anybody able to reproduce this? Tested with Gencase 4.0.092 and 4.0.109

## Comments

GenCase creates an initial lattice with size of dp.... Therefore the initial and final particle in one of the dimensions of your boxes will depend on that lattice size...

The boxes should be created with global dimensions of 1x1x1 however they will then converted in terms of "dp", perhaps for the third box extra layer of particles are created.... when using value of 0.12 instead of 0.15

You can visualise the positions of the particles at edges in paraview to understand if extra layer of particles are created when modifying "dp"

Regards

And to continue on Alex's explanation, this is also why it is extremely important, when working with floatings and you want an exact weight, to specify the weight directly! That way no matter if you have 50 or 60 particles it will have the weight you expect, instead of being some approximated number.

But I really like what you are doing by testing a lot of use cases of GenCase out, maybe stuff like this could be useful for new and experienced users on the Github wiki etc.

Kind regards

Thanks for all feedback. If I may take your comments as a confirmation that there is no formal error in my coding, then I would rise the level of concern. I agree that the assigned mass is conserved since particle count times particle mass matches the desired value. However please notice the following points

rotational properties of the floating objectsare messed up, said in blunt terms. For cubes I do expect an isotropic inertia tensor. For equal cubes I expect equal inertia tensors. In contrast, for dp=0.12 the floating mk52 has an isotropic inertia tensor: v22<v11=v33. And the deviation is not marginal. They are two cubes and a prism.Would you mind it terribly to reproduce these results for my peace of mind?

(As an aside please feel free to reuse all the material that I publish in this forum as you like. I do not have enough spare time to contribute to the wiki directly, but I certainly would if I could.)

(attempt to save jottings as draft comment failed)

I kept on playing around with GenCase and the three cubes above. They have edge lenght

L= 1m, massM=1 kgand theoretical isotropic moment of inertia ofI=1.667 kgm². The white cube shown in the sketch in the post above is centred in the origin of the reference frame and is Cube #1. The blue cube is Cube #2, the red is Cube #3.I have considered two design situations separately.

In the first one, the particle spacing dp is such that L/dp is an

integer. Each edge will contain exactly L/dp+1 particles and the cube 2*(L/dp + 1)³ particles neatly placed within the intended cube shape. (The factor 2 depends on modelling choices discussed elsewhere.) Here I consider a range 8-96 sufficient to cover many situations of practical interest.In the second one, thirty particle spacings are picked

randomlyso as to sample a uniform distribution of L/dp in the same interval 8-96. This represents the likely situation where a user chooses dp without a focus on floating objects.The results of these GenCase launches are in this plot:

## Integer L/dp

For integer L/dp's the inertia tensors of all cubes are isotropic. The numerical moment of inertia computed by DualSPHysics converges to the exact value linearly in Dp (not shown). This can be expected . The convergence of the computed isotropic moment of inertia is shown by the gray curve.

Note that, for the numerical moments are greater than the exact one,

a floating object in DualSPHysics will always behave more sluggishly than assigned: expect thus less angular acceleration for given torques, or a greater torque to obtain a given angular acceleration.Perhaps this is a wiki-worthy tip, useful to interpret progress and published results?## Arbitrary L/dp

For arbitrary L/dp's the situation is unexpectedly puzzling. Two forms of irregularity are evident: differences between cubes and anisotropy.

Concerning

consistency, I colour-coded the cubes with the same colours as in the earlier sketch, expect for swapping white with black.Concerning

anisotropy, the moments of inertia in x, y and z direction of a single cube are symbolized by a butterfly and downward or upward pointing triangles. These symbols overlap to a square when the inertia tensor is isotropic as expected. Symbols others than a square, conversely, indicate unexpected anisotropy. I also checked that the inertia products are zero as expected.The evidence gathered this way is that, with arbitrary L/dp, cube #1 is always isotropic but off the values obtained with integer L/dp's. Cube #1 and #2 are often anisotropic and quite often differ from each other. These irregularities are within about +/- 3% of the expected numerical values. Please note that symbols are not transparent, so colours may mask one another.

## Discussion

Unless I unintentionally succeeded in making a house of cards out of it, the

difference between the three cubesis just as unexpected as a for-loop that does not repeat the same instruction. I am still pretty puzzled by it; I cannot figure out any rationale to retrieve both isotropy and anisotropy from the identical cubes. Could it then be that fixing this loop issue also eliminates the lack of isotropy?Secondly, departures of isotropic moments from the grey curve

could be expectedfor non-integer L/dp's. If L/dp is an arbitrary number, the number of particles for discretizing a floating object has to be rounded up/down to an integer, say from 8.3333 to 8. So there can exist floating objects having the same number of particles but particles differently spaced because of the chosen dp. This will lead to a slightly different distribution of masses around the centre of mass, hence a different moment of inertia. However, this approximation should come with a bit of regularity that is not observable at this moment.## Conclusions

To derive these data sets I have consistently used the bash script attached, for anyone to double check, duplicate and verify. This launches a GenCase run, parses the resulting xml file and picks the inertia tensor values. I am grateful to anyone who points out glitches and faults. If this information is proven sound and reproducible, I hope it raises points for attentions worth triaging. Where applicable, a patch would be useful.

## Minor presentational feature request

When L/dp is a power of 2, the output is:

else it is

For generality, ease of scripting and control it would be ideal to show the full tensor throughout and to use a uniform number notation (say scientific).

Thanks for your reading and considering.