Re: [Yade-users] [Question #700434]: InsertionSortCollider SortAxis : does axis choice make a difference to speed?
Question #700434 on Yade changed: https://answers.launchpad.net/yade/+question/700434 Daniel Kiracofe posted a new comment: Jérôme, the initial report above was for a single iteration: O.run(1). To answer your question, I did a reset of the timing statistics and then ran for 100 iterations (very small verlet distance so collider was running every iteration) letting the particles settle under gravity. I did not see any statistically significant differences for those next 100 iterations. It is only the first initial sort where there are differences. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #700434]: InsertionSortCollider SortAxis : does axis choice make a difference to speed?
Question #700434 on Yade changed: https://answers.launchpad.net/yade/+question/700434 Status: Answered => Solved Daniel Kiracofe confirmed that the question is solved: Bruno, thank you for reply. I decided to try a few experiments. I created a highly elongated packing with an aspect ratio of 1:7:49. All particles were spheres with same diameter generated by makeCloud from yade.pack.SpherePack(). There were approximately 60,000 total particles. I used timing.stats() to pull out the time of the initial collider run. I ran both single threaded and with 4 threads to compare, but single threaded actually seemed to be a little faster so I'm reporting that here. Results: sortAxis = 0 (short axis), time = 11.8 s sortAxis = 1 (medium axis), time = 1.87 s sortAxis = 2 (long axis), time = 0.39s So actually a factor of 30 difference between the different axes. I tried a few variations on this with different aspect ratios and different number of particles, but general conclusion was that the long axis was MUCH faster. This highly elongated packing is perhaps a little uncommon in the general community, but if anyone else is using something like this, it could be useful information to know. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
[Yade-users] [Question #700434]: InsertionSortCollider SortAxis : does axis choice make a difference to speed?
New question #700434 on Yade: https://answers.launchpad.net/yade/+question/700434 InsertionSortCollider documentation says: "At the initial step, Bodies’ bounds (along sortAxis) are first std::sort’ed along this (sortAxis) axis, then collided. The initial sort has O(n^2) complexity,". But what is not stated is how to choose the sortAxis (or if it really matters). For example, if I have a box with dimensions 10x100x1000, is it better to pick sortAxis as the biggest dimension, or the smallest, or the one in between? Or are they all about the same? Mostly I'm concerned about the initial sort because of the aforementioned n^2 time, but if one choice is better for the initial sort and a different choice is better for subsequent steps I'd like to know that too. If it matters, in the above assume particle diameter=1, so 1 million total particles. Large enough that choices like this could have a significant impact on run time. If nobody has ever tried this, I can go run some experiments and see. But hoping to not reinvent the wheel -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #691021]: en averaging for Law2_ScGeom_ViscElPhys_Basic, bug or incorrect documentation?
Question #691021 on Yade changed: https://answers.launchpad.net/yade/+question/691021 Daniel Kiracofe posted a new comment: Yes, I am happy to make some suggested improvements via git merge requests. I'm not sure if I will find any more changes to this module or not, but I can make these changes now and if anything else related comes up later I can put that in too. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #691009]: et for ViscElMat with Law2_ScGeom_ViscElPhys_Basic, bug or feature?
Question #691009 on Yade changed: https://answers.launchpad.net/yade/+question/691009 Status: Answered => Solved Daniel Kiracofe confirmed that the question is solved: Yes exactly. Thank you! -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #691009]: et for ViscElMat with Law2_ScGeom_ViscElPhys_Basic, bug or feature?
Question #691009 on Yade changed: https://answers.launchpad.net/yade/+question/691009 Daniel Kiracofe confirmed that the question is solved: Thanks Bruno Chareyre, that solved my question. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
[Yade-users] [Question #691021]: en averaging for Law2_ScGeom_ViscElPhys_Basic, bug or incorrect documentation?
New question #691021 on Yade:
https://answers.launchpad.net/yade/+question/691021
The documentation for Law2_ScGeom_ViscElPhys_Basic
(https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom_ViscElPhys_Basic)
states the following:
The damping constant is computed at each contact in order to fulfill the
normal restitution coefficient en=(en1 en2)/(en1+en2)
However, this does not appear to be what is actually implemented. It looks to
me like the code actually does en = (en1+en2)/2
For example, if I test two materials, one with en=0.9 and the other with
en=0.1, the formula stated in the documentation would result in en = 0.9 * 0.1
/ (0.9 + 0.1) = 0.09. Example code with dropping a ball onto a wall is below.
The expected rebound height of the ball is square root of coefficient of
restitution times initial height. i.e. expect a rebound height of 1% of the
initial height. The actual rebound height that I get is 0.25, which implies
the coefficient of restitution is 0.5. That is consistent with an arithmetic
average (0.9+0.1)/2.
So, my question: should it be considered as the documentation is the intended
behavior and this is an issue with the code? or the code is the intended
behavior and this is an issue with the documentation? or neither one is right,
and it should be something else?
The behavior in the documentation does not make physical sense to me. imagine
two materials both with en=1. You would end up with (1*1)/(1+1) = 0.5. That
doesn't make sense. en=1 implies elastic behavior, but that's not what would
happen. So to me, I would suggest to keep current arithmetic averaging and
change the documentation to match.
In reality, of course, coefficient of restitution is not really defined for an
individual material, but only really for pair of materials (and even then only
empirically determined). I looked around to see if I could find any articles
of someone suggesting one averaging method or the other, but I could not find
any.
###
import matplotlib.pyplot as pyplot
from yade import qt, plot
qt.View() #open the controlling and visualization interfaces
box_x = 0.05
box_y = 0.05
box_z = 0.05
particle_dia = 0.005
young2 = 200e9
rho= 8230
mn = Vector3(0, box_y, 0)
mx = Vector3(box_x,2*box_y, box_z) #corners of the initial packing
thick = 2*particle_dia # the thickness of the walls
bigmx = (mx[0], 3 * mx[1], mx[2])
restitution_ball = 0.9
restitution_wall = 0.1
O.materials.append(ViscElMat(young=young2,poisson=0.7,frictionAngle=0, en =
restitution_ball , et=1, density=rho , label='ve_ball'))
O.materials.append(ViscElMat(young=young2,poisson=0.7,frictionAngle=0, en =
restitution_wall , et=1, density=rho , label='ve_wall'))
ball = sphere( (mx[0]/2, 2*mx[1] , mx[2]/2 ) , particle_dia/2,
material='ve_ball' )
ballIds = O.bodies.append(ball)
walls=utils.aabbWalls([mn,bigmx],thickness=thick,oversizeFactor=1.5,material='ve_wall')
wallIds=O.bodies.append(walls)
#turn on gravity and let it settle
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()] ),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
[Ip2_ViscElMat_ViscElMat_ViscElPhys()],
[Law2_ScGeom_ViscElPhys_Basic()] ),
NewtonIntegrator(gravity=(0,-9.81,0),damping=0.0),
PyRunner(command='addPlotData()', iterPeriod=1000),
]
O.dt=.05*PWaveTimeStep()
def addPlotData():
plot.addData(time=O.time , pos =
(O.bodies[ballIds].state.pos[1]-box_y)/0.15 )
plot.plots={'time':('pos')}
plot.plot()
#O.run(-1, True)
--
You received this question notification because your team yade-users is
an answer contact for Yade.
___
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #691009]: et for ViscElMat with Law2_ScGeom_ViscElPhys_Basic, bug or feature?
Question #691009 on Yade changed: https://answers.launchpad.net/yade/+question/691009 Status: Needs information => Open Daniel Kiracofe gave more information on the question: Bruno: I don't see any changes to cases 1-3. Those are handled by the other branches of the if-then-else tree starting here https://gitlab.com /yade-dev/trunk/-/blob/master/pkg/dem/ViscoelasticPM.cpp#L215 Only the last case would be affected. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #691009]: et for ViscElMat with Law2_ScGeom_ViscElPhys_Basic, bug or feature?
Question #691009 on Yade changed:
https://answers.launchpad.net/yade/+question/691009
Status: Answered => Open
Daniel Kiracofe is still having a problem:
Robert, the documentation I'm referring to this here: https://yade-
dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom_ViscElPhys_Basic
There are four different cases. I'm trying to do the fourth one:
"If Yound modulus (young), poisson’s ratio (poisson), normal and
tangential restitution coefficient (en,et) are precised, the equivalent
stiffnesses are evaluated as previously: Kn=2kn1kn2kn1+kn2, knx=Exdx,
Ks=2(ks1ks2)/(ks1+ks2), ksx=vknx. The damping constant is computed at
each contact in order to fulfill the normal restitution coefficient
en=(en1en2)/(en1+en2). This is achieved resolving numerically equation
21 of [Schwager2007] (There is in fact a mistake in the article from
equation 18 to 19, so that there is a change in sign). Be careful in
this configuration the tangential restitution coefficient is set to 1
(no tangential damping). This formulation imposes directly the normal
restitution coefficient of the collisions instead of the damping
constant."
The relevant line in the code is https://gitlab.com/yade-
dev/trunk/-/blob/master/pkg/dem/ViscoelasticPM.cpp#L263 and the
following 3 lines.
if et and en are specified, cn is calculated from en, and cs is set to
zero (so et is ignored). But if either et or en is omitted, then both
cs and cn are not set to anything (so default zero).
so why not just change line 263 to be:
} else if (isfinite(mat1->en) ) {
--
You received this question notification because your team yade-users is
an answer contact for Yade.
___
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp
[Yade-users] [Question #691009]: et for ViscElMat with Law2_ScGeom_ViscElPhys_Basic, bug or feature?
New question #691009 on Yade:
https://answers.launchpad.net/yade/+question/691009
I had an issue with ViscElMat, started to write a question, ended up solving it
myself. So now my question is really: is this a bug or a feature?
If you have a material like this
ViscElMat(young=200e9,poisson=0.7,frictionAngle=0, en = 0.5 , density=rho ,
label='ve')
and use InteractionLoop([Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
[Ip2_ViscElMat_ViscElMat_ViscElPhys()],[Law2_ScGeom_ViscElPhys_Basic()] ), in
O.engines the resulting behavior is completely elastic in the normal direction.
The coefficient of restitution is completely ignored. Same behavior
regardless of the value of en. (A full working example is below).
Now if you do:
ViscElMat(young=200e9,poisson=0.7,frictionAngle=0, en = 0.5 , et=1.0,
density=rho , label='ve')
Then you get the expected viscoelastic behavior, with differing response as en
is changed. But you also get the exact same behavior with this
ViscElMat(young=200e9,poisson=0.7,frictionAngle=0, en = 0.5 , et=0.0,
density=rho , label='ve')
or even this
ViscElMat(young=200e9,poisson=0.7,frictionAngle=0, en = 0.5 , et=1000.0,
density=rho , label='ve')
The value of et is completely ignored, as long as its specified. So if the
value is ignored, why force the user to specify it? Why not just ignore it all
the time? Is this a bug, or was this done intentionally for some reason?
FWIW, The fact that et is ignored is mentioned in the documentation for
Law2_ScGeom_ViscElPhys_Basic, but the fact that you get elastic behavior if et
is omitted is not.
Using yade version 20200511-3819~5bf8512~buster1
import matplotlib.pyplot as pyplot
from yade import qt, plot
qt.View() #open the controlling and visualization interfaces
box_x = 0.05
box_y = 0.05
box_z = 0.05
particle_dia = 0.005
young2 = 200e9
rho= 8230
mn = Vector3(0, box_y, 0)
mx = Vector3(box_x,2*box_y, box_z) #corners of the initial packing
thick = 2*particle_dia # the thickness of the walls
global ballIds
#first create a very tall loose pack
# sp=pack.SpherePack()
bigmx = (mx[0], 3 * mx[1], mx[2])
restitution = 0.8
#this always gives elastic behavior. ball rebounds more or less exactly to
starting height
O.materials.append(ViscElMat(young=young2,poisson=0.7,frictionAngle=0, en =
restitution , density=rho , label='ve'))
#this give viscoelastic behavior. ball rebounds to 64% of initial height as
expected. et is ignored, as long as it is specificed.
#O.materials.append(ViscElMat(young=young2,poisson=0.7,frictionAngle=0, en =
restitution , et=1000, density=rho , label='ve'))
ball = sphere( (mx[0]/2, 2*mx[1] , mx[2]/2 ) , particle_dia/2, material='ve' )
ballIds = O.bodies.append(ball)
walls=utils.aabbWalls([mn,bigmx],thickness=thick,oversizeFactor=1.5,material='ve')
wallIds=O.bodies.append(walls)
#turn on gravity and let it settle
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()] ),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
[Ip2_ViscElMat_ViscElMat_ViscElPhys()],
[Law2_ScGeom_ViscElPhys_Basic()] ),
NewtonIntegrator(gravity=(0,-9.81,0),damping=0.0),
PyRunner(command='addPlotData()', iterPeriod=100),
]
O.dt=.05*PWaveTimeStep()
def addPlotData():
plot.addData(time=O.time , pos =
(O.bodies[ballIds].state.pos[1]-box_y)/0.15 )
plot.plots={'time':('pos')}
plot.plot()
#O.run(-1, True)
--
You received this question notification because your team yade-users is
an answer contact for Yade.
___
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp
[Yade-users] [Question #690856]: can't get O.stopAtTime to work
New question #690856 on Yade: https://answers.launchpad.net/yade/+question/690856 I am having trouble getting O.stopAtTime to work. I tried this little script. From my understanding, this would run until either 400 iterations, or 20 seconds, whichever comes first. Actual result, runs for 400 iterations = 320 seconds. Went way past the intended stop time. O.stopAtTime = 20.0 O.stopAtIter = 400 O.run(-1, True) print(O.time) print(O.iter) So maybe it's not whichever comes first, it's whichever comes last. So then I tried this O.stopAtTime = 20.0 O.stopAtIter = 4 O.run(-1, True) print(O.time) print(O.iter) That runs for 4 iterations = 3.2 seconds. So it appears to be always using the value of O.stopAtIter, and O.stopAtTime is ignored. So then let's try this: O.stopAtTime = 20.0 O.run(-1, True) print(O.time) print(O.iter) This runs forever. I found this thread from 2014: https://answers.launchpad.net/yade/+question/246284 but the syntax suggested there O._sceneObj().stopAtTime no longer works. Running single threaded job with a recent daily build (Yade 20200511-3819~5bf8512~buster1) As a workaround, I can definitely put in a little PyRunner to periodically check O.time and pause when it hits a certain value, but it seems like that shouldn't be necessary. What am I missing? -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #690691]: setPermF broken?
Question #690691 on Yade changed: https://answers.launchpad.net/yade/+question/690691 Daniel Kiracofe confirmed that the question is solved: Thanks Bruno Chareyre, that solved my question. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #690691]: setPermF broken?
Question #690691 on Yade changed: https://answers.launchpad.net/yade/+question/690691 Status: Answered => Solved Daniel Kiracofe confirmed that the question is solved: Bruno, I have compiled branch fixPermForcesMultithread and verified that it does fix the bug I was experiencing. Thank you all for the help! Daniel -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #690691]: setPermF broken?
Question #690691 on Yade changed:
https://answers.launchpad.net/yade/+question/690691
Status: Answered => Open
Daniel Kiracofe is still having a problem:
Jan, I appreciate the quick reply. Here are some more details.
I was originally running with "yade -j 4". I tried it with just "yade",
but that did not change anything.
The original code was quite complicated. I tried to create a stripped
down version of my code to produce the minimum possible bug report. I
stripped it down to code #1 below. In that code, I create 4 walls which
are clumped together. if I apply the setPermF to the clump, it does not
work. If I apply the setPermF to an individual wall that is a member of
the clump, it does work.
However, in my original code, neither one of these worked. So I went
back to my original code again, and started stripping it down again to
try to get the minimum possible bug report for a single body that is not
part of a clump. I got code #2 below. In this code, I create a single
wall, and then either 0, 1 or a bunch of spheres. If I create a bunch
of spheres, then setPermF (on the wall) does not work. If I create 0 or
1 sphere, then it does work. Not quite sure what is going on here.
So, unless I'm doing something wrong or misunderstanding, it looks like there
may be three separate bugs with setPermF
1) the parallel vs single-threaded issue raised above
2) the clump vs single body issue demonstrated in code #1 below
3) the still unknown issue demonstrated in code #2 below
Please let me know if you need any more details.
Daniel
#
#code #1
#in this version, setPermF works if I apply to one of the members of the clump
#but does not work if apply it directly to the clump
###3
box_x = 0.00025
box_y = 0.0013
box_z = box_y
f_sweep_start = 45.5 #
f_sweep_stop = 52 #Hertz
f_sweep_rate = 1 #Hertz/second
out_file_name = "TestOutput.txt"
F_amp = 4e-6
grav_y=0
damp = 0.000
ball_gen_method=1
#
import qt, plot
qt.View() #open the controlling and visualization interfaces
finalFricDegree = atan(0.25) #contact friction during the deviatoric loading
young2 = 200e9 #the walls' Young's modulus, same as the spheres
rho= 8230 #
mn = Vector3(0, box_y, 0)
mx = Vector3(box_x,2*box_y, box_z) #corners of the initial packing
thick = 0.010 # the thickness of the walls
nat_freq_hz = 50.0
nat_period = 1 / nat_freq_hz
nat_freq_rad = nat_freq_hz * 2 * math.pi
#GENERATING BODIES #
O.dt = nat_period / 100
plotDataPeriod = 10
#special 4 walls case for 2D because of all of the blocked DOF
expand=1.5
walls_density = 8000
wallIds = []
O.materials.append(FrictMat(young=young2,poisson=0.7,frictionAngle=0,
density=walls_density , label='walls'))
# yade.utils.box( center extents= half sizes!
topWall = yade.utils.box( (box_x/2,2*box_y+thick/2,box_z/2),
(box_x/2*expand,thick/2,box_z/2*expand), material='walls')
topWallId = O.bodies.append(topWall)
wallIds.append(topWallId)
botWall = yade.utils.box( (box_x/2,box_y-thick/2,box_z/2),
(box_x/2*expand,thick/2, box_z/2*expand), material='walls')
botWallId = O.bodies.append(botWall)
wallIds.append(botWallId)
rightWall = yade.utils.box( (box_x+thick/2,1.5*box_y,box_z/2),
(thick/2,box_y/2*expand, box_z/2*expand), material='walls')
rightWallId = O.bodies.append(rightWall)
wallIds.append(rightWallId)
leftWall = yade.utils.box( (-thick/2,1.5*box_y,box_z/2),
(thick/2,box_y/2*expand, box_z/2*expand), material='walls')
leftWallId = O.bodies.append(leftWall)
wallIds.append(leftWallId)
wallClump=O.bodies.clump(wallIds)
for i in wallIds:
O.bodies[i].state.blockedDOFs = 'xzXYZ' #fixme is this needed with
clumping?
#DEFINING ENGINES
newton=NewtonIntegrator(damping=damp, gravity=(0,grav_y,0))
O.engines=[
ForceResetter(),
PyRunner(command='swing()',iterPeriod=100),
newton,
PyRunner(command='addPlotData()',iterPeriod=plotDataPeriod),
]
def swing():
force = 5
#this works
#O.forces.addF( wallClump, ( 0, force , 0) )
#this does not work
O.forces.setPermF( wallClump , ( 0, force , 0) )
#this does work
#O.forces.setPermF( topWallId , ( 0, force , 0) )
def addPlotData():
position=O.bodies[topWallId].state.pos[1]
plot.addData(freq=O.time , position=position)
plot.plots={'freq':('position')}
plot.plot()
###
###
#code #2
from yade import pack
#this variable selection between three cases
#ball_gen_method=0, generates one wall and zero spheres, then setPermF on the
wall works
#ball_gen_method=1, generates one wall and one spheres, then setPermF on t
[Yade-users] [Question #690691]: setPermF broken?
New question #690691 on Yade: https://answers.launchpad.net/yade/+question/690691 I have a user-defined force that I need to apply to a clump. The force changes with time, but rather slowly relative to the time step. I noticed that the PyRunner to calculate and apply this force was taking 20 - 30% of the entire simulation time, so I thought to recalculate the force only every 100 iterations or so. I was previously using this to apply the force O.forces.addF(ClumpId, ( 0, externalForce , 0) ) I switched it to this: O.forces.setPermF(ClumpId, ( 0, externalForce , 0) ) The result is that the clump in question does not move. It's as if zero force was applied to it. I checked O.forces.permF(ClumpId), and it gives me the expected force, but the body does not move. I also tried addF with permanent=True, also adding the force directly to a single member of the clump instead of the clump directly. None of these work. Any suggestions? Or anybody can point me a to working example of setPermF? I am using recent daily build (20200511-3819~5bf8512~buster1). Here's the key part of the source: O.engines=[ ForceResetter(), InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()], verletDist=verlet_dist ), InteractionLoop( [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_FrictPhys()], [Law2_ScGeom_FrictPhys_CundallStrack()] ), timestepper, PyRunner(command='swing()',iterPeriod=100), newton, PyRunner(command='addPlotData()',iterPeriod=plotDataPeriod), ] def swing(): global theta theta = 2 * math.pi * ( f_sweep_start * O.time + f_sweep_rate * O.time**2) extF = F_amp * math.sin(theta) kF = -k * ( wall_state.pos[1]-x0 ) cF = -c * ( wall_state.vel[1] ) # O.forces.addF( ClumpId, ( 0, extF + kF + cF , 0) ) # works O.forces.setPermF(ClumpId, ( 0, extF + kF +cF , 0) ) # does nothing? -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #686177]: Compilation Issues on Centos 7
Question #686177 on Yade changed: https://answers.launchpad.net/yade/+question/686177 Status: Open => Solved Daniel Kiracofe confirmed that the question is solved: Answering my own question in case anyone else has the same problem. I finally fixed this by removing the CentOS boost package (1.69), downloading and compiling the latest boost package (1.71) directly from the source. This worked. I don't know if this represents a bug in YADE, a bug in Boost, or a problem with the CentOS packaging. One way or the other it worked. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #686178]: Compilation Issues on Centos 7
Question #686178 on Yade changed: https://answers.launchpad.net/yade/+question/686178 Status: Open => Solved Daniel Kiracofe confirmed that the question is solved: sorry accidentally posted twice. closing one of them. -- You received this question notification because your team yade-users is an answer contact for Yade. ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp
Re: [Yade-users] [Question #686178]: Compilation Issues on Centos 7
Question #686178 on Yade changed:
https://answers.launchpad.net/yade/+question/686178
Description changed to:
Hi I'm contemplating using YADE for a research project. We have a high
performance cluster at my university and I want to run YADE on that.
The cluster uses Centos 7 (it's a little dated I know but that's what
they've got). Trying to compile the code and getting an issue. Here is
the error message:
[ 13%] Building CXX object CMakeFiles/yade.dir/pkg/common/ForceEngine.cpp.o
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:2: error: stray ‘#’ in program
BOOST_HEADER_DEPRECATED("");
^
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:97: note: #pragma message: This
header is deprecated. Use instead.
BOOST_HEADER_DEPRECATED("");
^
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:4: error: expected unqualified-id
before numeric constant
BOOST_HEADER_DEPRECATED("");
^
In file included from /usr/include/boost/random/detail/integer_log2.hpp:21:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/random/detail/disable_warnings.hpp:27:28: error: expected
declaration before end of line
#pragma GCC diagnostic push
^
make[2]: *** [CMakeFiles/yade.dir/pkg/common/ForceEngine.cpp.o] Error 1
make[1]: *** [CMakeFiles/yade.dir/all] Error 2
make: *** [all] Error 2
I tried the 2019.01a release as well as a git clone of the most recent trunk
and both gave the same error.
Looks like some issue related to boost library. I have installed version
1.69 from the RHEL EPEL 7 release repository (again I know thats a
little dated, but its the most recent one available for Centos 7...
would like to avoid compiling boost myself if I have to). GCC version is
4.8.5
For what it's worth, the cmake configuration is here:
-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Found unsuitable Qt version "" from NOTFOUND
-- Version is set to 2019.01a
-- Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY
OPENGL_INCLUDE_DIR)
-- GSL using pkgconfig
-- WARNING: you are using the obsolete 'PKGCONFIG' macro, use FindPkgConfig
-- PKGCONFIG() indicates that gts is not installed (install the package which
contains gts.pc if you want to support this feature)
FindGTS.cmake: gts-config/pkg-config
[Yade-users] [Question #686177]: Compilation Issues on Centos 7
New question #686177 on Yade:
https://answers.launchpad.net/yade/+question/686177
Hi I'm contemplating using YADE for a research project. We have a high
performance cluster at my university and I want to run YADE on that. The
cluster uses Centos 7 (it's a little dated I know but that's what they've got).
Trying to compile the code and getting an issue. Here is the error message:
[ 13%] Building CXX object CMakeFiles/yade.dir/pkg/common/ForceEngine.cpp.o
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:2: error: stray ‘#’ in program
BOOST_HEADER_DEPRECATED("");
^
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:97: note: #pragma message: This
header is deprecated. Use instead.
BOOST_HEADER_DEPRECATED("");
^
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:4: error: expected unqualified-id
before numeric constant
BOOST_HEADER_DEPRECATED("");
^
In file included from /usr/include/boost/random/detail/integer_log2.hpp:21:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/random/detail/disable_warnings.hpp:27:28: error: expected
declaration before end of line
#pragma GCC diagnostic push
^
make[2]: *** [CMakeFiles/yade.dir/pkg/common/ForceEngine.cpp.o] Error 1
make[1]: *** [CMakeFiles/yade.dir/all] Error 2
make: *** [all] Error 2
I tried the 2019.01a release as well as a git clone of the most recent trunk
and both gave the same error.
Looks like some issue related to boost library. I have installed version 1.69
from the RHEL EPEL 7 release library (again I know thats a little dated, but
its the most recent one available for Centos 7... would like to avoid compiling
boost myself if I have to). GCC version is 4.8.5
For what it's worth, the cmake configuration is here:
-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Found unsuitable Qt version "" from NOTFOUND
-- Version is set to 2019.01a
-- Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY
OPENGL_INCLUDE_DIR)
-- GSL using pkgconfig
-- WARNING: you are using the obsolete 'PKGCONFIG' macro, use FindPkgConfig
-- PKGCONFIG() indicates that gts is not installed (install the package which
contains gts.pc if you want to support this feature)
FindGTS.cmake: gts-config/pkg-config gts not found. Please
[Yade-users] [Question #686178]: Compilation Issues on Centos 7
New question #686178 on Yade:
https://answers.launchpad.net/yade/+question/686178
Hi I'm contemplating using YADE for a research project. We have a high
performance cluster at my university and I want to run YADE on that. The
cluster uses Centos 7 (it's a little dated I know but that's what they've got).
Trying to compile the code and getting an issue. Here is the error message:
[ 13%] Building CXX object CMakeFiles/yade.dir/pkg/common/ForceEngine.cpp.o
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:2: error: stray ‘#’ in program
BOOST_HEADER_DEPRECATED("");
^
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/large_arithmetic.hpp" left
but not entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/detail/const_mod.hpp" left but not
entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/usr/include/boost/random/linear_congruential.hpp" left but
not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
line-map.c: file "/root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp" left
but not entered
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:97: note: #pragma message: This
header is deprecated. Use instead.
BOOST_HEADER_DEPRECATED("");
^
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/pending/integer_log2.hpp:7:4: error: expected unqualified-id
before numeric constant
BOOST_HEADER_DEPRECATED("");
^
In file included from /usr/include/boost/random/detail/integer_log2.hpp:21:0,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/linear_congruential.hpp:30,
from /root/yade_2019.01a/trunk/pkg/common/ForceEngine.cpp:13:
/usr/include/boost/random/detail/disable_warnings.hpp:27:28: error: expected
declaration before end of line
#pragma GCC diagnostic push
^
make[2]: *** [CMakeFiles/yade.dir/pkg/common/ForceEngine.cpp.o] Error 1
make[1]: *** [CMakeFiles/yade.dir/all] Error 2
make: *** [all] Error 2
I tried the 2019.01a release as well as a git clone of the most recent trunk
and both gave the same error.
Looks like some issue related to boost library. I have installed version 1.69
from the RHEL EPEL 7 release library (again I know thats a little dated, but
its the most recent one available for Centos 7... would like to avoid compiling
boost myself if I have to). GCC version is 4.8.5
For what it's worth, the cmake configuration is here:
-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Found unsuitable Qt version "" from NOTFOUND
-- Version is set to 2019.01a
-- Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY
OPENGL_INCLUDE_DIR)
-- GSL using pkgconfig
-- WARNING: you are using the obsolete 'PKGCONFIG' macro, use FindPkgConfig
-- PKGCONFIG() indicates that gts is not installed (install the package which
contains gts.pc if you want to support this feature)
FindGTS.cmake: gts-config/pkg-config gts not found. Please
