Yade 2019.01a vs. gitlab version

Asked by Bettina Suhr on 2019-08-27

Dear all,

until now, I used Yade 2019.01a for my computations. Recently, I also downloaded and installed the current version from gitlab. When I compare the results obtained from both versions, I see (small) differences. I’m a bit worried, because I do not see such differences between Yade 2018.02b and Yade 2019.01a.

An example for the obtained differences can be seen in the 03-oedometric-test.py script. I added “seed=1” in the makeCloud command and obtain identical initial positions for the spheres (wrt. yade version). The particles settle under gravity. When the unbalanced force is below 0.1, a plate is inserted for compression. The position of the plate is above the highest sphere in the packing and already here there are differences (note: I changed the PyRunner iterPeriod for a better comparison: PyRunner(command='checkUnbalanced()',iterPeriod=100,label='checker') )

#add plate at position: 0.549239607153 at iteration: 10300 # Yade 2018.02b
#add plate at position: 0.549239607153 at iteration: 10300 # Yade 2019.01a
#add plate at position: 0.575951497648 at iteration: 9800# yade gitlab compiled with Python 2
#add plate at position: 0.5759514976482029 at iteration: 9800# yade gitlab compiled with Python 3

For backward compatibility, I think it’s worth investigating, what causes these changes. Do you agree?
Do you have any suggestion, how I can track these changes down?

Thanks and best regards,

Question information

English Edit question
Yade Edit question
No assignee Edit question
Last query:
Last reply:

Hi Bettina,

> Do you agree?

Thanks for reporting.

I suspect a change done recently in order to make results *more reproducible* [1], especially with multithreaded (-jN) runs.
But of course it introduces a difference between older and newer results (they are all equally correct, though). It appeared in the master branch in June, so if you could compare 7a4a71ef (after change) to 900c7616 (before) it could confirm that.

If it doesn't:
- Could you paste here the exact script you are using, so everyone can reproduce the "#add plate..." messages?

- are timesteps the same?
- are all positions exactly the same at iteration 0, then 1? (you can just sum all positions together and compare the result to make it simpler)



[1] https://gitlab.com/yade-dev/trunk/commit/68d600d283914d74693cd42ed0b0eb89eefa3c98

Unlike what the commit message suggests most of the reproducibility is obtained even if loopOnSortedInteractions=False.

Bettina Suhr (bettina-suhr) said : #2

Dear Bruno,

Thanks a lot for your answer and your suggestions.

The time steps are the same as well as the initial positions of the spheres.

Due to some technical difficulties it may take some days until I can compare the two commits, which you mentioned. I will post the results then.

Best regards,

Bettina Suhr (bettina-suhr) said : #3

Dear all,

I tried to do the checks, which Bruno suggested, but I didn’t succeed.
After checking out the commit 900c7616, running cmake and make clean, I get an error in compilation:

/home/bettinasuhr/yade-gitlab/trunk/pkg/common/InsertionSortCollider.cpp:526:22: error: invalid use of member function ‘size_t InsertionSortCollider::VecBounds::size() const’ (did you forget the ‘()’ ?)
    for(long i=0; i<V.size; i++){
CMakeFiles/yade.dir/build.make:504: recipe for target 'CMakeFiles/yade.dir/pkg/common/InsertionSortCollider.cpp.o' failed
make[2]: *** [CMakeFiles/yade.dir/pkg/common/InsertionSortCollider.cpp.o] Error 1
CMakeFiles/Makefile2:142: recipe for target 'CMakeFiles/yade.dir/all' failed
make[1]: *** [CMakeFiles/yade.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

Did I do something wrong? This looks to me like a typo in the code of InsertionSortCollider.cpp

If somebody can run these tests easier than me, below is the script, which I used to obtain the results posted above.

Thanks and regards,

# gravity deposition, continuing with oedometric test after stabilization
# shows also how to run parametric studies with yade-batch

# The components of the batch are:
# 1. table with parameters, one set of parameters per line (ccc.table)
# 2. readParamsFromTable which reads respective line from the parameter file
# 3. the simulation muse be run using yade-batch, not yade
# $ yade-batch --job-threads=1 03-oedometric-test.table 03-oedometric-test.py

# load parameters from file if run in batch
# default values are used if not run from batch
# make rMean, rRelFuzz, maxLoad accessible directly as variables later
from yade.params.table import *
from yade import export,ymport

# create box with free top, and ceate loose packing inside the box
from yade import pack, plot
sp.makeCloud((0,0,0),(1,1,1),rMean=rMean,rRelFuzz=rRelFuzz, seed=1)

 # sphere, facet, wall
  # the loading plate is a wall, we need to handle sphere+sphere, sphere+facet, sphere+wall
 # the label creates an automatic variable referring to this engine
 # we use it below to change its attributes from the functions called

# the following checkUnbalanced, unloadPlate and stopUnloading functions are all called by the 'checker'
# (the last engine) one after another; this sequence defines progression of different stages of the
# simulation, as each of the functions, when the condition is satisfied, updates 'checker' to call
# the next function when it is run from within the simulation next time

# check whether the gravity deposition has already finished
# if so, add wall on the top of the packing and start the oedometric test
def checkUnbalanced():
 # at the very start, unbalanced force can be low as there is only few contacts, but it does not mean the packing is stable
 #print (O.iter, unbalancedForce())
 if O.iter<5000: return
 # the rest will be run only if unbalanced is < .1 (stabilized packing)
 if unbalancedForce()>.1: return
 # add plate at the position on the top of the packing
 # the maximum finds the z-coordinate of the top of the topmost particle
 print ('add plate at position: ', max([b.state.pos[2]+b.shape.radius for b in O.bodies if isinstance(b.shape,Sphere)]) ,'at iteration: ', O.iter)
 O.bodies.append(wall(max([b.state.pos[2]+b.shape.radius for b in O.bodies if isinstance(b.shape,Sphere)]),axis=2,sense=-1))
 global plate # without this line, the plate variable would only exist inside this function
 plate=O.bodies[-1] # the last particles is the plate
 # Wall objects are "fixed" by default, i.e. not subject to forces
 # prescribing a velocity will therefore make it move at constant velocity (downwards)
 # start plotting the data now, it was not interesting before
 # next time, do not call this function anymore, but the next one (unloadPlate) instead

def unloadPlate():
 # if the force on plate exceeds maximum load, start unloading
 if abs(O.forces.f(plate.id)[2])>maxLoad:
  # next time, do not call this function anymore, but the next one (stopUnloading) instead

def stopUnloading():
 if abs(O.forces.f(plate.id)[2])<minLoad:
  # O.tags can be used to retrieve unique identifiers of the simulation
  # if running in batch, subsequent simulation would overwrite each other's output files otherwise
  # d (or description) is simulation description (composed of parameter values)
  # while the id is composed of time and process number

def addPlotData():
 if not isinstance(O.bodies[-1].shape,Wall):
  plot.addData(); return

# besides unbalanced force evolution, also plot the displacement-force diagram


# when running with yade-batch, the script must not finish until the simulation is done fully
# this command will wait for that (has no influence in the non-batch mode)

Thanks for trying. Maybe there was indeed a typo in that specific commit and it was fixed in another one. Unfortunately I don't think I'll manage to try it very soon. For now I would say there is no reason to panic, most likely the situation with latest versions is ok, but it would be worth verifying.

Can you help with this problem?

Provide an answer of your own, or ask Bettina Suhr for more information if necessary.

To post a message you must log in.