Problems with manipulation force container after erasing some bodies

Asked by Karol Brzezinski

Hi,

I encountered a problem with manipulation of force container after I erase some bodies from simulation. For example, command O.forces.reset() results in 'segmentation core fault'. I have found a 'dirty fix' to this (setting zero permF to any of the left bodies). However, I don't understand this behavior. How should it be properly handled?

# this code works
O.bodies.append([sphere((0,0,i),0.5) for i in range(3)])
O.forces.reset()
#

# this code fails
O.bodies.append([sphere((0,0,i),0.5) for i in range(3)])
O.bodies.erase(0)
O.forces.reset()
#

#but this works
O.bodies.append([sphere((0,0,i),0.5) for i in range(3)])
O.bodies.erase(0)
O.forces.setPermF(1,(0,0,0))
O.forces.reset()
#

I am using Ubuntu 20.04. I have tried this on different versions of Yadedaily (e.g 20210923-5934~44b94a0~focal1) and on Yade 2020.01a.

Best wishes,
KB

Question information

Language:
English Edit question
Status:
Solved
For:
Yade Edit question
Assignee:
No assignee Edit question
Solved by:
Karol Brzezinski
Solved:
Last query:
Last reply:
Revision history for this message
Jan Stránský (honzik) said :
#1

Hello,

what is the reason to call O.forces.reset() manually?
What is the result of O.forces.reset(resetAll=false)?
What if you call it after O.step()?

In the c++ source, resetAll=false by default [1] and also this way used by ForceResetter [2].
However, resetAll=True is used in Python [3].
The problem probably is in "resetAll=true" if-branch [4,5,6], trying to reset _permForce container, but probably it is not properly resized.

Concerning segmentation fault, you would get more info using catchsegv.
What is the output of "catchsegv yade script.py"? ("yade" replaced by actual version and "script.py" by actual script name)

> a problem with manipulation of force container after I erase some bodies from simulation.

what are other "manipulations"?

> However, I don't understand this behavior. How should it be properly handled?

It should be properly handled such that the source code is fixed for the cases you need :-)
The reason of current behavior is that nobody used it / needed it this way so far, so the inconsistencies and mistakes remained hidden.

Feel free to open an issue on gitlab if you find current state not OK.

Cheers
Jan

[1] https://gitlab.com/yade-dev/trunk/-/blob/master/core/ForceContainer.hpp#L130
[2] https://gitlab.com/yade-dev/trunk/-/blob/master/pkg/common/ForceResetter.hpp#L13
[3] https://gitlab.com/yade-dev/trunk/-/blob/master/py/wrapper/yadeWrapper.cpp#L1699
[4] https://gitlab.com/yade-dev/trunk/-/blob/master/core/ForceContainerSerial.cpp#L116
[5] https://gitlab.com/yade-dev/trunk/-/blob/master/core/ForceContainerSerial.cpp#L130
[6] https://gitlab.com/yade-dev/trunk/-/blob/master/core/ForceContainerParallel.cpp#L218

Revision history for this message
Karol Brzezinski (kbrzezinski) said :
#3

Hi Jan,

I used the O.forces.reset() in my example, to make it simpler. However, this may be confusing because the problem occurs in a slightly different situation actually (while reading permF). After your response, it is quite obvious that I can avoid the problem by storing permF information separately - since I am the one who is setting this in the first place ;) The issue itself surprised me. However, the problem turns out to be silly. I am still glad that I asked the question. Thank you!

Cheers,
Karol

Revision history for this message
Jan Stránský (honzik) said :
#4

> the problem turns out to be silly

it is not silly. It is a regular bug (existence of workarounds does not change it).

Cheers
Jan