Re: [Yade-dev] Release, GitLab?

2019-01-28 Thread Janek Kozicki 
> > - Should we disable commits on github?  
> I think so. Last commits are the pull request from Boon, I merged them 
> into gitlab already.
> Keeping github open after the migration would be misleading.

agreed. Especially we should do this when release happens.
I merged his latest commits too.
 
> > - Should all links in the Yade code be updated to GitLab variants?  
> It should be the case already. The doc in gitlab repo is visible here 
> [1] and points to gitlab. I did not find any other github link in sources.
> There is still a need to 1/ redirect yade-dem.org to those pages or 2/ 
> upload the pages on yade-dem.org.

try command

  grep github . -irn --exclude ChangeLog --color

there are still  some mentions of github in documentation.

> A related issue, maybe, is that the search box is disabled on gitlab.io. 
> We discussed that with Rémi without a clear conclusion yet.
> Any idea?

I don't know anything about the searchbox yet.

> Also, I just found that I searched-replaced a bit too hastly in [1], 
> which led to a broken link to https://gitlab.com/yade-dev/yadedaily/  in 
> [2].
> I guess we can also migrate yadedaily repo (and make it point to gitlab 
> simultaneously)? It would fix that link.
> 
> [1] https://yade-dev.gitlab.io/trunk/installation.html
> [2] https://yade-dev.gitlab.io/trunk/installation.html#packages

agreed.

> > - Do we prepare release from GitLab?  
> Yes if you don't see problems with that. It is the most up-to-date given 
> the github/gitlab link replacement mentioned above.

yes.

> > Also we need to decide, how this release will be done. As usually,
> > creating 2019.01-branch and tagging the release there? Or creating
> > the single "stable" branch for all other future releases?  
> I would say "as usual".

I would prefer stable branch and tags. But it doesn't matter that
much. We can do "as usual", no problem ;)

Although it would be nice if we deleted stale branches on

  https://gitlab.com/yade-dev/trunk/branches/stale

not all of them. Just those which are no longer needed. But still we
have a backup copy here (if its ever needed):

  https://gitlab.com/yade-dev/trunk-exp/branches/stale

I ask about this for a very simple reason: so that the command

  git branch -a

is easier to read.

> > I am ready to postpone the release for the next couple of days to
> > solve this questions, if necessary.  
> 
> I am ready to postpone the freeze of github for the same reason. ;)
> If there is no problem releasing from gitlab now, then we can declare 
> migration effective and close github.

let's postpone it one or two days. I still didn't finish writing in
documentation the short descriptions of all examples :)

best regards
Janek

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Fixing the examples

2019-01-28 Thread Janek Kozicki 
Jan Stránský said: (by the date of Sun, 20 Jan 2019 21:44:29 +0100)

> > If you have any hints on how to fix any of those examples, please tell!  
> 
> several mentioned not working script is from me. I think than correcting
> them and pushing to gitlab is better than telling :-)


Hi Jan,

I'm not sure if you have seen my question on
https://gitlab.com/yade-dev/trunk/merge_requests/40

1. you marked helix.py as working. I would expect the sphere to move
in a helix around the rod. But this does not happen.

Why do you mark it as working? Maybe it is working and I just don't
see it. I only would like some explanation :)


2. pv_section.py - wow, works nicely in paraview, but only after I
commented out line 45 and 51, otherwise I had this error:

  File "", line 45, in 
NameError: name 'HideScalarBarIfNotNeeded' is not defined
  File "", line 51, in 
NameError: name 'HideScalarBarIfNotNeeded' is not defined

For now I commented these two lines. Maybe you have a better idea.

I just pushed a new commit to
https://gitlab.com/yade-dev/trunk/commits/fix/examples
please have a look.

-- 
Janek Kozicki

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] LOG_DEBUG spamming

2019-01-28 Thread Janek Kozicki 
yep. Sorry for the false alarm. With -DDEBUG=0 it is good ;)

Janek Kozicki said: (by the date of Mon, 28 Jan 2019 19:18:06 +0100)

> Bruno Chareyre said: (by the date of Mon, 28 Jan 2019 18:07:35 +0100)
> 
> > On 1/28/19 5:29 PM, Janek Kozicki wrote:  
> > > Bruno Chareyre said: (by the date of Fri, 25 Jan 2019 17:26:47 +0100)
> > >
>  [...]  
> > > So what do we do:
> > > - comment them out in the code
> > > - or make LOG_DEBUG silent default?
> > >
> > 
> > Wait, are you saying that even LOG_DEBUG are displayed with non-debug 
> > build (then it is a problem)?
> > What I meant was that LOG_WARN was always displayed. However LOG_DEBUG 
> > should appear only for debug build (then it is ok).  
> 
> ouch, my bad. I was always compiling with -DDEBUG=1, and I forgot
> about that. I will recompile with -DDEBUG=0 and check again! :)
> 
> 
> -- 
> Janek Kozicki
> 
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp


-- 
Janek Kozicki   http://janek.kozicki.pl/  |

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] LOG_DEBUG spamming

2019-01-28 Thread Janek Kozicki 
Bruno Chareyre said: (by the date of Mon, 28 Jan 2019 18:07:35 +0100)

> On 1/28/19 5:29 PM, Janek Kozicki wrote:
> > Bruno Chareyre said: (by the date of Fri, 25 Jan 2019 17:26:47 +0100)
> >  
> >>
> >> Should definitely not appear. A remaining of the times when logging was
> >> more fine-grained and LOG_DEBUG was silent by default.  
> > So what do we do:
> > - comment them out in the code
> > - or make LOG_DEBUG silent default?
> >  
> 
> Wait, are you saying that even LOG_DEBUG are displayed with non-debug 
> build (then it is a problem)?
> What I meant was that LOG_WARN was always displayed. However LOG_DEBUG 
> should appear only for debug build (then it is ok).

ouch, my bad. I was always compiling with -DDEBUG=1, and I forgot
about that. I will recompile with -DDEBUG=0 and check again! :)


-- 
Janek Kozicki

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] LOG_DEBUG spamming

2019-01-28 Thread Bruno Chareyre 




On 1/28/19 5:29 PM, Janek Kozicki wrote:

Bruno Chareyre said: (by the date of Fri, 25 Jan 2019 17:26:47 +0100)



Should definitely not appear. A remaining of the times when logging was
more fine-grained and LOG_DEBUG was silent by default.

So what do we do:
- comment them out in the code
- or make LOG_DEBUG silent default?



Wait, are you saying that even LOG_DEBUG are displayed with non-debug 
build (then it is a problem)?
What I meant was that LOG_WARN was always displayed. However LOG_DEBUG 
should appear only for debug build (then it is ok).


Bruno



___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] LOG_DEBUG spamming

2019-01-28 Thread Janek Kozicki 
Bruno Chareyre said: (by the date of Fri, 25 Jan 2019 17:26:47 +0100)

> > InteractionLoop.cpp:73 action: Body #76 vanished, erasing intr #76+#97!
> > InteractionLoop.cpp:73 action: Body #21 vanished, erasing intr #21+#96!
> > InteractionLoop.cpp:73 action: Body #21 vanished, erasing intr #21+#2!
> >
> > Are really spamming the terminal. Yes they are nice. But we should do 
> > something
> > about default setting of LOG_DEBUG messages to not spam people who don't
> > understand what's going on. Actually that was a reason for which
> > I marked some examples as either suspicious or not working. And that
> > wasn't an error introduced by the author of the example.  
>
> Should definitely not appear. A remaining of the times when logging was 
> more fine-grained and LOG_DEBUG was silent by default.

This is also the case for FEMxDEM examples. It's scrolling very fast.
Some which I have located:

ForceContainerParallel.cpp:224
InsertionSortCollider.cpp:207
Omega.cpp:106
yadeWrapper.cpp:635
yadeWrapper.cpp:641

So what do we do:
- comment them out in the code
- or make LOG_DEBUG silent default?

-- 
Janek Kozicki

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Potential Blocks and Potential Particles - Documentation

2019-01-28 Thread Chia Weng Boon 
Sorry I missed clicking the subsequent buttons.  I just merged upstream,
committed and pulled again.

https://github.com/yade/trunk/pulls

Boon

On Sun, Jan 27, 2019 at 11:06 PM Janek Kozicki  wrote:

> Hi Boon,
>
> great thanks. I think that fixing orientation should be possible :)
> I cannot find your pull request though. Can you send a link?
>
> cheers
> Janek
>
> Chia Weng Boon said: (by the date of Sun, 27 Jan 2019 22:28:11 +0800)
>
> > Hi Janek,
> > I submitted a Pull Request.  I fixed the display for the free fall
> examples
> > using Marching Cubes.  However, the orientation of the particles are not
> > completely correct yet in QT.  See for example the Wedge Example.
> > I think that was the reason why I moved to ParaView.
> >
> > Boon
> >
> > On Sat, Jan 26, 2019 at 11:19 PM Janek Kozicki 
> wrote:
> >
> > > Hi Boon,
> > >
> > > thanks for you reply. Yes, I think that this marching cubes method
> > > can work really good. The only missing thing is to make the caching
> > > of calculated triangles correctly. Once the triangles for the shape
> > > are calculated you can use them all the time, unless the body deforms
> or
> > > is cut in half (I'm not sure if this can happen).
> > >
> > > A thing to discuss: you could store cached triangles not inside
> > > Gl1_PotentialParticle but inside PotentialParticle with Attr::hidden
> > > or (Attr::hidden|Attr::noSave). For example see into
> > > pkg/common/Cylinder.hpp as an example. In this way you will not need
> > > this loop in pkg/common/Gl1_PotentialParticle.cpp line 112, and
> > > automatically you have solved the problem what to draw when a body
> > > was deleted or added to scene. Because you only recalculate marching
> > > cubes for particular single body when you need to draw it and it
> > > wasn't generated yet.
> > >
> > > I hope that the post which I have just sent to mailing list about
> > > object oriented design deficiencies of your code wasn't too harsh.
> > > My apologies.
> > >
> > > best regards
> > > Janek
> > >
> > > Chia Weng Boon said: (by the date of Sat, 26 Jan 2019 11:12:40
> +0800)
> > >
> > > > Dear Janek,
> > > > I will look into it. Thanks. In the python script, the vtk files at
> > > > specific time intervals are output into the vtk folder.  I have
> been
> > > using
> > > > ParaView mainly for visualisation for both Potential Particles and
> > > > Potential Blocks.  The colour of the particles can also be changed in
> > > > ParaView.  I suspect that the Marching Cube display is not showing
> the
> > > > position and size of the particles correctly (I abandoned the
> marching
> > > > cubes quite long ago, but agree that real time display with
> simulation is
> > > > more user friendly)
> > > >
> > > > Let me check the example files again.
> > > >
> > > > Boon
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~yade-dev
> > > Post to : yade-dev@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~yade-dev
> > > More help   : https://help.launchpad.net/ListHelp
> > >
>
>
> --
> Janek Kozicki   http://janek.kozicki.pl/  |
>
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Fixing the examples FEMxDEM

2019-01-28 Thread Janek Kozicki 
Yes, thanks. I figured this out ;) Two of those FEMxDEM scripts are now
working for me. I will write in docs how to make them run.

Three are still not working. One of them seems to have a simple
mistake which I could probably fix (file footing.py):

  from msFEM import MultiScale

msFEM does not exist. Available are msFEM2D, msFEM3D, msFEMup.
I suppose that I could just replace that with msFEM2D, because then it
works. But I have no way to tell if it works correctly, so maybe
better leave it as is.

The other two triaxialRough.py and undrain.py are complaining about
missing OPAL_SUCCESS and ompi_mpi_init. So I leave them for now.

Whoa, I see lots of gitlab activity in the morning. I will go and check
what happened :)

Bruno Chareyre said: (by the date of Mon, 28 Jan 2019 10:10:03 +0100)

> On 1/27/19 6:40 PM, Janek Kozicki wrote:
> > ImportError: No module named yadeimport  
> In case you are wondering, that's the usual alias name for importing yade:
> ln -s yade yadeimport.py
> 
> Just because python would not import without *.py.
> 
> Bruno
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp


-- 
Janek Kozicki   http://janek.kozicki.pl/  |

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1813550] Re: FlowEngine memory leak - 600 Mb/hr

2019-01-28 Thread Bruno Chareyre 
Good one!
Can you push this to a gitlab branch for merge?
Tell me if you need help.
Bruno

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1813550

Title:
  FlowEngine memory leak - 600 Mb/hr

Status in Yade:
  Fix Committed

Bug description:
  Running examples/oedometer.py with 8000 spheres, flow.useSolver=4 and
  tracking RAM usage, I find we have a memory leak of 600 Mb/hr.

  examples/oedometer.py with num_spheres=8000:

  # -*- coding: utf-8 -*-

  from yade import pack

  num_spheres=8000# number of spheres
  young=1e6
  compFricDegree = 3 # initial contact friction during the confining phase
  finalFricDegree = 30 # contact friction during the deviatoric loading
  mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
  walls=aabbWalls([mn,mx],thickness=0,material='walls')
  wallIds=O.bodies.append(walls)

  sp=pack.SpherePack()
  sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
  sp.toSimulation(material='spheres')

  triax=TriaxialStressController(
   maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
   finalMaxMultiplier=1.+2e3/young, # spheres growing factor (slow growth)
   thickness = 0,
   stressMask = 7,
   max_vel = 0.005,
   internalCompaction=True, # If true the confining pressure is generated by 
growing particles
  )

  newton=NewtonIntegrator(damping=0.2)

  O.engines=[
   ForceResetter(),
   InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
   InteractionLoop(
    [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
    [Ip2_FrictMat_FrictMat_FrictPhys()],
    [Law2_ScGeom_FrictPhys_CundallStrack()],label="iloop"
   ),
   FlowEngine(dead=1,label="flow"),#introduced as a dead engine for the moment, 
see 2nd section
   
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=100,timestepSafetyCoefficient=0.8),
   triax,
   newton
  ]

  triax.goal1=triax.goal2=triax.goal3=-1

  while 1:
    O.run(1000, True)
    unb=unbalancedForce()
    if unb<0.001 and abs(-1-triax.meanStress)/1<0.001:
  break

  setContactFriction(radians(finalFricDegree))

  ## __   Oedometer section   _

  #A. Check bulk modulus of the dry material from load/unload cycles
  triax.stressMask=2
  triax.goal1=triax.goal3=0

  triax.internalCompaction=False
  triax.wall_bottom_activated=False
  #load
  triax.goal2=-11000; O.run(2000,1)
  #unload
  triax.goal2=-1; O.run(2000,1)
  #load
  triax.goal2=-11000; O.run(2000,1)
  e22=triax.strain[1]
  #unload
  triax.goal2=-1; O.run(2000,1)

  e22=e22-triax.strain[1]
  modulus = 1000./abs(e22)

  #B. Activate flow engine and set boundary conditions in order to get 
permeability
  flow.dead=0
  flow.defTolerance=0.3
  flow.meshUpdateInterval=200
  flow.fluidBulkModulus=2.2e9
  flow.useSolver=4
  flow.desiredPorosity=0
  flow.permeabilityFactor=1
  flow.viscosity=10
  flow.bndCondIsPressure=[0,0,1,1,0,0]
  flow.bndCondValue=[0,0,1,0,0,0]
  flow.boundaryUseMaxMin=[0,0,0,0,0,0]
  O.dt=0.1e-3
  O.dynDt=False

  O.run(1,1)
  Qin = flow.getBoundaryFlux(2)
  Qout = flow.getBoundaryFlux(3)
  permeability = abs(Qin)/1.e-4 #size is one, we compute K=V/∇H
  print "Qin=",Qin," Qout=",Qout," permeability=",permeability

  #C. now the oedometer test, drained at the top, impermeable at the bottom 
plate
  flow.bndCondIsPressure=[0,0,0,1,0,0]
  flow.bndCondValue=[0,0,0,0,0,0]
  flow.updateTriangulation=True #force remeshing to reflect new BC immediately
  newton.damping=0

  #we want the theoretical value from Terzaghi's solution
  #keep in mind that we are not in an homogeneous material and the small strain
  #assumption is not verified => we don't expect perfect match
  #there can be also an overshoot of pressure in the very beginning due to 
dynamic effects
  Cv=permeability*modulus/1e4
  zeroTime=O.time
  zeroe22 = - triax.strain[1]
  dryFraction=0.05 #the top layer is affected by drainage on a certain depth, 
we account for it here
  drye22 = 1000/modulus*dryFraction
  wetHeight=1*(1-dryFraction)

  def consolidation(Tv): #see your soil mechanics handbook...
   U=1
   for k in range(50):
    M=pi/2*(2*k+1)
    U=U-2/M**2*exp(-M**2*Tv)
   return U

  triax.goal2=-11000

  from yade import plot

  ## a function saving variables
  def history():
     
plot.addData(e22=-triax.strain[1]-zeroe22,e22_theory=drye22+(1-dryFraction)*consolidation((O.time-zeroTime)*Cv/wetHeight**2)*1000./modulus,t=O.time,p=flow.getPorePressure((0.5,0.1,0.5)),s22=-triax.stress(3)[1]-1)
     
#plot.addData(e22=-triax.strain[1],t=O.time,s22=-triax.stress(2)[1],p=flow.MeasurePorePressure((0.5,0.5,0.5)))

[Yade-dev] [Bug 1813550] [NEW] FlowEngine memory leak - 600 Mb/hr

2019-01-28 Thread Robert Caulk 
Public bug reported:

Running examples/oedometer.py with 8000 spheres, flow.useSolver=4 and
tracking RAM usage, I find we have a memory leak of 600 Mb/hr.

examples/oedometer.py with num_spheres=8000:

# -*- coding: utf-8 -*-

from yade import pack

num_spheres=8000# number of spheres
young=1e6
compFricDegree = 3 # initial contact friction during the confining phase
finalFricDegree = 30 # contact friction during the deviatoric loading
mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
walls=aabbWalls([mn,mx],thickness=0,material='walls')
wallIds=O.bodies.append(walls)

sp=pack.SpherePack()
sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
sp.toSimulation(material='spheres')

triax=TriaxialStressController(
 maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
 finalMaxMultiplier=1.+2e3/young, # spheres growing factor (slow growth)
 thickness = 0,
 stressMask = 7,
 max_vel = 0.005,
 internalCompaction=True, # If true the confining pressure is generated by 
growing particles
)

newton=NewtonIntegrator(damping=0.2)

O.engines=[
 ForceResetter(),
 InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
 InteractionLoop(
  [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
  [Ip2_FrictMat_FrictMat_FrictPhys()],
  [Law2_ScGeom_FrictPhys_CundallStrack()],label="iloop"
 ),
 FlowEngine(dead=1,label="flow"),#introduced as a dead engine for the moment, 
see 2nd section
 
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=100,timestepSafetyCoefficient=0.8),
 triax,
 newton
]

triax.goal1=triax.goal2=triax.goal3=-1

while 1:
  O.run(1000, True)
  unb=unbalancedForce()
  if unb<0.001 and abs(-1-triax.meanStress)/1<0.001:
break

setContactFriction(radians(finalFricDegree))

## __   Oedometer section   _

#A. Check bulk modulus of the dry material from load/unload cycles
triax.stressMask=2
triax.goal1=triax.goal3=0

triax.internalCompaction=False
triax.wall_bottom_activated=False
#load
triax.goal2=-11000; O.run(2000,1)
#unload
triax.goal2=-1; O.run(2000,1)
#load
triax.goal2=-11000; O.run(2000,1)
e22=triax.strain[1]
#unload
triax.goal2=-1; O.run(2000,1)

e22=e22-triax.strain[1]
modulus = 1000./abs(e22)

#B. Activate flow engine and set boundary conditions in order to get 
permeability
flow.dead=0
flow.defTolerance=0.3
flow.meshUpdateInterval=200
flow.fluidBulkModulus=2.2e9
flow.useSolver=4
flow.desiredPorosity=0
flow.permeabilityFactor=1
flow.viscosity=10
flow.bndCondIsPressure=[0,0,1,1,0,0]
flow.bndCondValue=[0,0,1,0,0,0]
flow.boundaryUseMaxMin=[0,0,0,0,0,0]
O.dt=0.1e-3
O.dynDt=False

O.run(1,1)
Qin = flow.getBoundaryFlux(2)
Qout = flow.getBoundaryFlux(3)
permeability = abs(Qin)/1.e-4 #size is one, we compute K=V/∇H
print "Qin=",Qin," Qout=",Qout," permeability=",permeability

#C. now the oedometer test, drained at the top, impermeable at the bottom plate
flow.bndCondIsPressure=[0,0,0,1,0,0]
flow.bndCondValue=[0,0,0,0,0,0]
flow.updateTriangulation=True #force remeshing to reflect new BC immediately
newton.damping=0

#we want the theoretical value from Terzaghi's solution
#keep in mind that we are not in an homogeneous material and the small strain
#assumption is not verified => we don't expect perfect match
#there can be also an overshoot of pressure in the very beginning due to 
dynamic effects
Cv=permeability*modulus/1e4
zeroTime=O.time
zeroe22 = - triax.strain[1]
dryFraction=0.05 #the top layer is affected by drainage on a certain depth, we 
account for it here
drye22 = 1000/modulus*dryFraction
wetHeight=1*(1-dryFraction)

def consolidation(Tv): #see your soil mechanics handbook...
 U=1
 for k in range(50):
  M=pi/2*(2*k+1)
  U=U-2/M**2*exp(-M**2*Tv)
 return U

triax.goal2=-11000

from yade import plot

## a function saving variables
def history():
   
plot.addData(e22=-triax.strain[1]-zeroe22,e22_theory=drye22+(1-dryFraction)*consolidation((O.time-zeroTime)*Cv/wetHeight**2)*1000./modulus,t=O.time,p=flow.getPorePressure((0.5,0.1,0.5)),s22=-triax.stress(3)[1]-1)
   
#plot.addData(e22=-triax.strain[1],t=O.time,s22=-triax.stress(2)[1],p=flow.MeasurePorePressure((0.5,0.5,0.5)))

O.engines=O.engines+[PyRunner(iterPeriod=200,command='history()',label='recorder')]
##make nice animations:
#O.engines=O.engines+[PyRunner(iterPeriod=200,command='flow.saveVtk()')]

from yade import plot
plot.plots={'t':('e22','e22_theory',None,'s22','p')}
plot.plot()
O.saveTmp()
O.timingEnabled=1
from yade import timing
print "starting oedometer simulation"
O.run(200,1)
timing.stats()

## Make more steps to see the convergence to the stationnary solution

** Affects: yade
 Importance: High
 Assignee: Robert Caulk (rcaulk)
 Status: Fix Committed

**

[Yade-dev] [Bug 1813550] Re: FlowEngine memory leak - 600 Mb/hr

2019-01-28 Thread Robert Caulk 
flow.reuseOrdering functionality makes a copy of the factor for
efficient reuse. Algorithm was not freeing unnecessary copies.

Fixed with:

line 173 FLowBoundingSphereLinSolv.ipp:

if (!multithread && factorExists && useSolver==4){
if (getCHOLMODPerfTimings) gettimeofday (, NULL); 
cholmod_l_free_sparse(, );
cholmod_l_free_triplet(, );
if (!reuseOrdering) {
cholmod_l_free_factor(, );
++  cholmod_l_free_factor(, );  <<<++
cholmod_l_finish();
if (getCHOLMODPerfTimings){
gettimeofday (, NULL);
cout << "CHOLMOD Time to finalize 
singlethreaded com " << ((end.tv_sec *100   + end.tv_usec ) - (start.tv_sec 
* 100 + start.tv_usec )) << endl;
}
cholmod_l_start();
}
com.nmethods= 1; // nOrderingMethods; //1;
com.method[0].ordering = CHOLMOD_METIS; // orderingMethod; 
//CHOLMOD_METIS;
factorExists=false; 

}

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1813550

Title:
  FlowEngine memory leak - 600 Mb/hr

Status in Yade:
  Fix Committed

Bug description:
  Running examples/oedometer.py with 8000 spheres, flow.useSolver=4 and
  tracking RAM usage, I find we have a memory leak of 600 Mb/hr.

  examples/oedometer.py with num_spheres=8000:

  # -*- coding: utf-8 -*-

  from yade import pack

  num_spheres=8000# number of spheres
  young=1e6
  compFricDegree = 3 # initial contact friction during the confining phase
  finalFricDegree = 30 # contact friction during the deviatoric loading
  mn,mx=Vector3(0,0,0),Vector3(1,1,1) # corners of the initial packing

  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
  
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
  walls=aabbWalls([mn,mx],thickness=0,material='walls')
  wallIds=O.bodies.append(walls)

  sp=pack.SpherePack()
  sp.makeCloud(mn,mx,-1,0.,num_spheres,False, 0.95,seed=1) #"seed" make the 
"random" generation always the same
  sp.toSimulation(material='spheres')

  triax=TriaxialStressController(
   maxMultiplier=1.+2e4/young, # spheres growing factor (fast growth)
   finalMaxMultiplier=1.+2e3/young, # spheres growing factor (slow growth)
   thickness = 0,
   stressMask = 7,
   max_vel = 0.005,
   internalCompaction=True, # If true the confining pressure is generated by 
growing particles
  )

  newton=NewtonIntegrator(damping=0.2)

  O.engines=[
   ForceResetter(),
   InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
   InteractionLoop(
    [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
    [Ip2_FrictMat_FrictMat_FrictPhys()],
    [Law2_ScGeom_FrictPhys_CundallStrack()],label="iloop"
   ),
   FlowEngine(dead=1,label="flow"),#introduced as a dead engine for the moment, 
see 2nd section
   
GlobalStiffnessTimeStepper(active=1,timeStepUpdateInterval=100,timestepSafetyCoefficient=0.8),
   triax,
   newton
  ]

  triax.goal1=triax.goal2=triax.goal3=-1

  while 1:
    O.run(1000, True)
    unb=unbalancedForce()
    if unb<0.001 and abs(-1-triax.meanStress)/1<0.001:
  break

  setContactFriction(radians(finalFricDegree))

  ## __   Oedometer section   _

  #A. Check bulk modulus of the dry material from load/unload cycles
  triax.stressMask=2
  triax.goal1=triax.goal3=0

  triax.internalCompaction=False
  triax.wall_bottom_activated=False
  #load
  triax.goal2=-11000; O.run(2000,1)
  #unload
  triax.goal2=-1; O.run(2000,1)
  #load
  triax.goal2=-11000; O.run(2000,1)
  e22=triax.strain[1]
  #unload
  triax.goal2=-1; O.run(2000,1)

  e22=e22-triax.strain[1]
  modulus = 1000./abs(e22)

  #B. Activate flow engine and set boundary conditions in order to get 
permeability
  flow.dead=0
  flow.defTolerance=0.3
  flow.meshUpdateInterval=200
  flow.fluidBulkModulus=2.2e9
  flow.useSolver=4
  flow.desiredPorosity=0
  flow.permeabilityFactor=1
  flow.viscosity=10
  flow.bndCondIsPressure=[0,0,1,1,0,0]
  flow.bndCondValue=[0,0,1,0,0,0]
  flow.boundaryUseMaxMin=[0,0,0,0,0,0]
  O.dt=0.1e-3
  O.dynDt=False

  O.run(1,1)
  Qin = flow.getBoundaryFlux(2)
  Qout = flow.getBoundaryFlux(3)
  permeability = abs(Qin)/1.e-4 #size is one, we compute K=V/∇H
  print "Qin=",Qin," Qout=",Qout," permeability=",permeability

  #C. now the oedometer test, drained at the top, impermeable at the bottom 
plate
  flow.bndCondIsPressure=[0,0,0,1,0,0]
  flow.bndCondValue=[0,0,0,0,0,0]
  flow.updateTriangulation=True #force remeshing to reflect new BC immediately
  newton.damping=0

  #we want the theoretical value from Terzaghi's solution
  #keep in mind that we are

Re: [Yade-dev] Release, GitLab?

2019-01-28 Thread Bruno Chareyre 

Hi Anton,


On 1/27/19 6:50 PM, Anton Gladky wrote:

- Should we disable commits on github?
I think so. Last commits are the pull request from Boon, I merged them 
into gitlab already.

Keeping github open after the migration would be misleading.


- Should all links in the Yade code be updated to GitLab variants?
It should be the case already. The doc in gitlab repo is visible here 
[1] and points to gitlab. I did not find any other github link in sources.
There is still a need to 1/ redirect yade-dem.org to those pages or 2/ 
upload the pages on yade-dem.org.


A related issue, maybe, is that the search box is disabled on gitlab.io. 
We discussed that with Rémi without a clear conclusion yet.

Any idea?

Also, I just found that I searched-replaced a bit too hastly in [1], 
which led to a broken link to https://gitlab.com/yade-dev/yadedaily/  in 
[2].
I guess we can also migrate yadedaily repo (and make it point to gitlab 
simultaneously)? It would fix that link.


[1] https://yade-dev.gitlab.io/trunk/installation.html
[2] https://yade-dev.gitlab.io/trunk/installation.html#packages

- Do we prepare release from GitLab?
Yes if you don't see problems with that. It is the most up-to-date given 
the github/gitlab link replacement mentioned above.



Also we need to decide, how this release will be done. As usually,
creating 2019.01-branch and tagging the release there? Or creating
the single "stable" branch for all other future releases?

I would say "as usual".



I am ready to postpone the release for the next couple of days to
solve this questions, if necessary.


I am ready to postpone the freeze of github for the same reason. ;)
If there is no problem releasing from gitlab now, then we can declare 
migration effective and close github.


Thanks for your help.

Bruno



___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

[Yade-dev] [Bug 1813488] Re: build robot location moved during gitlab switch?

2019-01-28 Thread Bruno Chareyre 
Hi Janek,
It is actually still correct. The github->buildbot->yadedaily pipe is still 
active.
But of course it will be replaced by gitlab pipeline. Thanks for spotting that, 
it will become a valid bug soon. ;)
Bruno

-- 
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1813488

Title:
  build robot location moved during gitlab switch?

Status in Yade:
  New

Bug description:
  Hi, in ./doc/sphinx/prog.rst line 118 it is written:

  A build robot hosted at `3SR lab. 
`__ 
  is tracking souce code changes.
  ...
  The buildbot activity and logs can be `browsed online 


  Is that still correct?

To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1813488/+subscriptions

___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Fixing the examples FEMxDEM

2019-01-28 Thread Bruno Chareyre 




On 1/27/19 6:40 PM, Janek Kozicki wrote:

ImportError: No module named yadeimport

In case you are wondering, that's the usual alias name for importing yade:
ln -s yade yadeimport.py

Just because python would not import without *.py.

Bruno



___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp