Rock falling through simulated terrain about siconos HOT 11 CLOSED

Hi @davidpilz,

I saw that there is a curious behavior of the contact points and the normal in LROC_simulation_falling.hdf5. Some normal are clearly in the wrong direction. I think this is the reason why the blocks are falling through the heightmap.

Unfortunately, I am not able to reproduce your example since a file is missing :

[vincent@ohana-2]$ python3 LROC_simulation_falling.py -g Euclides_K_map.asc -s Euclides_K_soil.asc -b Euclides_K_positions.asc -m rocks_params.csv -n soil_params.csv
Traceback (most recent call last):
  File "/Users/vincent/siconos-tutorials/examples/mechanics/RockFall/Falling/LROC_simulation_falling.py", line 47, in <module>
    import helperfunctions as hf
ModuleNotFoundError: No module named 'helperfunctions'

could you provide me with this file ?

from siconos.

Oh sorry. I forgot to include the external I/O functions in this file..
The newly uploaded version should work as a standalone script.
It is around the 12.8 to 13.8 time mark when one rock passes through the terrain.
Ok interesting, that some normals are off..

If there are any other questions / comprehension problems with the script, please let me know!
(Btw. the logic flaw concerning the coordinate system of the simulated vs. input height map (#455) is in this script as well. It should not affect the contact detection though and I would not change it at the moment to keep the problem reproduceable.)

from siconos.

Thank you.

The script is now running on my computer, but I am not able to reproduce the fact that some blocks fall through the terrain. Is there some randomized variable in the definition of the system?

I will try to launch several simulations.

from siconos.

Urgh, you are right. I am using random numbers to generate my shape.
Because I seeded the random number generator, I am consistently able to reproduce the issue on my machine.
Probably the seed differs on your machine though...

I updated the script to only simulate the block in question. But apparently, the shape is not saved to the same accuracy in the .hdf5 (is there a way to access the numbers directly?) as it is used in the simulation.
This results not exactly in the same behaviour (the shape probably just differs ever so slightly from the one created using random numbers), but leaves us with a rock stuck in the surface.

This is visible in siconos_vview with:

siconos_vview LROC_simulation_falling.hdf5 --camera=238.039099411391,508.6334718275114,395.88977061735096 --lookat=300.27728076859256,42.532637672839755,370.3252192663471 --up=-0.20872949905767774,-0.08132532625688521,0.9745861621900559

The rock starts to interact with the terrain at around 13.8, moves slightly further and then gets stuck for the rest of the time.

from siconos.

Hi @davidpilz

I am still not able to reproduce your problem, but I saw that normal vectors at contact are sometimes oriented downward.

I just pushed a fix that assumed that normal vectors must be upward (in the z-direction) when we perform collision with heighmap:
23ad9cb

With this fix, all the normal are coherently oriented.

If you do not want to completely reinstall siconos. I think you can apply only the small modifications directly into your siconos file.

from siconos.

EDIT:
I think I found the culprit: I set the initial orientation to, what I thought was just some random value, [1, 1, 1, 1] ... Thinking that any quaternion would work for a rotation in 3D space.
But what is probably used in siconos is some sort of the Euler-Rodrigues formula where the Euler parameters are written as a (unit) quaternion.
Is that assumption correct? What convention is used for the position of the parameters in the quaternion?

Setting it to all zeros and one random 1 results in a reasonable simulation now.

I still leave my other thoughts and questions attached below.

Hmm that is very interesting...
Is it normal, that the behaviour of siconos differs that much from machine to machine?
I double checked and at least no random numbers should be used in the script - the only reason I could think of such differences.
Maybe there is some other part I am missing?

I just installed the new version of siconos (just to be up to date with all modifications).
Now for me the rock is not stuck anymore at one position, but still clips partially through the surface and slides further down 'inside' the terrain (though all contact forces are upward now).
Judging from the visual appearance, a thought would be that there might be a problem with collision detection once a vertex immerges under the surface. The whole time after immersion, a contact force vector points from the immerged vertex upwards but does not seem able to change the body's position.
Maybe because it collides with the surface from the other side again? (I am not sure if collision detection works differently on the 'backside' of the terrain)

Another interesting fact I found is that most of the time there seems to be no contact force from other vertices immerged in the terrain.
Is there some logic in siconos that tries to correct a body's position once it clips through the terrain?
Or is it all about passive collision detection and prevention of such a difficult case?

from siconos.

For the quaternion, you need indeed to define unit quaternion for the orientation of the body w.r.t to the global frame.

For a rotation given by a angle $\theta$ and a rotation vector $\vec{n} = [n_x, n_y, n_z ]$ the corresponding unit quaternion is

$$ q = [\cos(\theta/2), n_x \sin(\theta/2), n_y \sin(\theta/2), n_z\sin(\theta/2)] $$

from siconos.

Normally, the behavior of siconos should not change to much across the platform for a given version. A crucial point is the version of bullet that is linked to siconos and the fact that it is compiled in double precision or float precision. This last option may change the accuracy of contact computations.

Another interesting fact I found is that most of the time there seems to be no contact force from other vertices immerged in the terrain.

The number of contact points between object is defined by bullet_options (see for instance https://gricad-gitlab.univ-grenoble-alpes.fr/nonsmooth/siconos-tutorials/-/blob/master/examples/mechanics/GranularMaterial/chute_con_rocas.py):

from siconos.mechanics.collision.bullet import SiconosBulletOptions
bullet_options = SiconosBulletOptions()

# default behavior
#bullet_options.perturbationIterations = 0
#bullet_options.minimumPointsPerturbationThreshold = 0
# 4 contact points (maximum between two object)
bullet_options.perturbationIterations = 4
bullet_options.minimumPointsPerturbationThreshold = 4

Other options are

bullet_options.clearOverlappingPairCache
bullet_options.dimension 
bullet_options.perturbationIterations
bullet_options.worldScale                        
bullet_options.contactBreakingThreshold 
bullet_options.enablePolyhedralContactClipping                           
bullet_options.contactProcessingThreshold
bullet_options.enableSatConvex   
bullet_options.Depth2D
bullet_options.minimumPointsPerturbationThreshold
 bullet_options.useAxisSweep3  

that corresponds to options in bullet3

from siconos.

I do not know if I answered to all your questions. Do not hesitate to make an updated list of questions if needed.

from siconos.

Ah ok, that makes sense. Thank you for your explanations!

Regarding the bullet options as well as the various siconos options:
Is there any set of recommended options for the simulation of rockfalls (convex bodies rolling/sliding/bouncing on a complex height map ; similar resolution of the height map (~2m/pixel to ~5m/pixel) compared to bodies' dimensions (max diameter 5m) ; starting velocities < 1m/s) that you could provide me with?
As I am not aware of any sensitivity analysis / profound parameter exploration published regarding siconos, I don't really know how much each parameter influences the overall simulation and what the optimal values would be for the given task.

from siconos.

Additionally I was wondering, is there any option to exclude rocks from propagating further once they reached a minimum velocity threshold to speed up the simulation?
In my case the simulation processes a lot more interactions during the end of the simulation, as most rocks will be slowly sliding/lying on the surface by then. Such tiny movements are not that relevant to my case but use up a lot of processing time.

from siconos.