Re: [Yade-dev] [Branch ~yade-dev/yade/trunk] Rev 2659: - Add relAngVel function to ScGeom (a similar version can be called from python as done for incid...
@Bruno: I would like to add the incremental formulation to CFLaw, how do you suggest to do that? Maybe I can use a bool something like (useIncrementalForm)? Sure! 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] [Branch ~yade-dev/yade/trunk] Rev 2662: Fix cache line size in OpenMPArrayAccumulator
revno: 2662
committer: Giulia Macaro giulia@engs-19155
branch nick: yade
timestamp: Wed 2011-01-19 10:21:31 +
message:
Fix cache line size in OpenMPArrayAccumulator
modified:
lib/base/openmp-accu.hpp
--
lp:yade
https://code.launchpad.net/~yade-dev/yade/trunk
Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to
https://code.launchpad.net/~yade-dev/yade/trunk/+edit-subscription
=== modified file 'lib/base/openmp-accu.hpp'
--- lib/base/openmp-accu.hpp 2010-11-25 20:20:58 +
+++ lib/base/openmp-accu.hpp 2011-01-19 10:21:31 +
@@ -28,8 +28,8 @@
size_t nCL; // current number of allocated cache lines
int nCL_for_N(size_t n){ return n/perCL+(n%perCL==0 ? 0 : 1); } // return number of cache lines to allocate for given number of elements
public:
- OpenMPArrayAccumulator(): CLS(sysconf(_SC_LEVEL1_DCACHE_LINESIZE)), nThreads(omp_get_max_threads()), perCL(CLS/sizeof(T)), chunks(nThreads,NULL), sz(0), nCL(0) { }
- OpenMPArrayAccumulator(size_t n): CLS(sysconf(_SC_LEVEL1_DCACHE_LINESIZE)), nThreads(omp_get_max_threads()), perCL(CLS/sizeof(T)), chunks(nThreads,NULL), sz(0), nCL(0) { resize(n); }
+ OpenMPArrayAccumulator(): CLS(sysconf(_SC_LEVEL1_DCACHE_LINESIZE)0 ? sysconf(_SC_LEVEL1_DCACHE_LINESIZE) : 64), nThreads(omp_get_max_threads()), perCL(CLS/sizeof(T)), chunks(nThreads,NULL), sz(0), nCL(0) { }
+ OpenMPArrayAccumulator(size_t n): CLS(sysconf(_SC_LEVEL1_DCACHE_LINESIZE)0 ? sysconf(_SC_LEVEL1_DCACHE_LINESIZE) : 64), nThreads(omp_get_max_threads()), perCL(CLS/sizeof(T)), chunks(nThreads,NULL), sz(0), nCL(0) { resize(n); }
// change number of elements
void resize(size_t n){
if(n==sz) return; // nothing to do
___
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] Cell deformation handling
Hi Bruno, I think it makes sense what you write and it is good that you did the implementaiton that works. The fact that flipCell can be encapsulated inside the collider is nice, for instance. I would like to just ask for 2 things: 1. Make sure that the old interface (setting refSize etc) works, there is already quite a few people having script that use it and they should not break (the scripts I mean, but perhaps people would break as well). 2. Update not only the documentation of the class, but also the DEM formulation chapter on periodic cell (https://www.yade-dem.org/doc/formulation.html#periodic-boundary-conditions) Cheers, v. Hi Vaclav, thanks for reply. I actually finished the implementation in the meantime. Cell.trsf defines the current (not initial) transformation of the cell with regards to the reference configuration, which is always axis-aligned box with size Cell.refSize. (Footnote: although I did not check bzr log, I am quite sure it was me who introduced Cell.trsf.) Cell.trsf is accumulated from Cell.velGrad. Yes, that's what I described : trsf is defining the initial _geometry_. (footnote : my bad, sorry. I only introduced incrementation on velGrad basis then.) If you suggest to define the reference (initial) geometry by using general parallelepiped (instead of axis-aligned box), I would oppose; not that it does not make sense geometrically, but brings quite a bit of complexity where the current facilities are enough. That is what I suggest indeed. Actually, this suggestion came after fixing an obvious mistake in Cell interface, which triggered a code cleaning spree. It would make things simpler and help clarify in the long run, else I would not bother. PBCs and related engines code is excessively complex and overconstrained currently. Removing the axis-aligned constraint makes things more general without adding any complexity. PBCs offer the opportunity of writing (1) frame invariant and (2) shape-independant mechanics by just controlling velGrad and stresses in periodic engines, but this advantage is not really used currently. One reason is the lack of clear split between what is needed/modified for mechanics, for contact detection, and for graphical representation. Overall, mixing all of them results in contaminating the mechanical parts with frame-dependant and (initial)shape-dependant code, which is never a good thing. A few examples : - velGrad is describing a mechanical effect and is reflected in trsf, but at the same time trsf is used to describe the initial geometry. So, it is useless for the user, who has to maintain his own material transformation. Even worst, trsf can be changed for contact detection (flipCell), while this could be hidden away in collider internals. - shearTrsf and friends are not describing shear in the mechanical sense. It is only something that we use for colliding and display, it results in misleading semantic. - refSize is (partialy) describing the initial shape, so it should not influence mechanics at all. Unfortunately, it is used in many places in PeriEngines, it is used to redefine Hsize at each step (not needed), can be modified by users and even by OGLrenderer (?!). It sounds insecure. The suggested change is a small step in the good direction regarding this sort of problems (introducing velGrad and Hsize was on the same line btw). 2. If you need reference (initial) cell that is already deformed, then you can always subtract (in the sense of transformation matrices, i.e. something like A^-1*B*(A^-1)^T) the initial trsf from the current one to get the part that corresponds to material transformation. It would work, but this is the sort of complexity that arbitrary initial shapes would remove. Do you have some concrete scenario in mind? Not saying that it can not exist, but I've never seen the initial sample to be periodic obliquely. Check Jan's scripts (reason why I mentionned him in o.p.)? I do have scenarii too. Also important, it clarifies and help writing frame invariant mechanics. Local diffs pass reg. tests and gives stable stress-strain behaviour starting from non-rectangular box. refSize is not used anywhere, except in OGLRenderer. Functionalities used in existing scripts (refSize=..; trsf=...) are preserved, though it doesn't really help simplifying the code. The new thing is you can prescribe arbitrary initial geometry (Hsize=...) while keeping trsf null. Would you give it a chance? 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 ___ 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] Cell deformation handling
Hi, It's commited. Attributes doc should be ok but header doc and sphinx doc are TODOs. All scripts I could find seems to run unmodified. I replaced definition of trsf and refSize by setters in the scripts (couldn't find a better way since integrateAndUpdate can't really do the job now). Setters are defined in such a way that they reproduce the older functionality (trsf=0 only if Hsize is axisAligned). Hsize setter allows arbitrary shape. The beauty of this is that there is no change at all in collider and display, since they use shearTrsf, itself defined on the basis of Hsize, indepently of trsf! There are a few places where I replaced refSize by size, it should be safe at first sight but I'll double check. The fact that flipCell can be encapsulated inside the collider is nice, for instance. Oh wait, this one is not done yet, ok? Cheers! Bruno I would like to just ask for 2 things: 1. Make sure that the old interface (setting refSize etc) works, there is already quite a few people having script that use it and they should not break (the scripts I mean, but perhaps people would break as well). 2. Update not only the documentation of the class, but also the DEM formulation chapter on periodic cell (https://www.yade-dem.org/doc/formulation.html#periodic-boundary-conditions) Cheers, v. Hi Vaclav, thanks for reply. I actually finished the implementation in the meantime. Cell.trsf defines the current (not initial) transformation of the cell with regards to the reference configuration, which is always axis-aligned box with size Cell.refSize. (Footnote: although I did not check bzr log, I am quite sure it was me who introduced Cell.trsf.) Cell.trsf is accumulated from Cell.velGrad. Yes, that's what I described : trsf is defining the initial _geometry_. (footnote : my bad, sorry. I only introduced incrementation on velGrad basis then.) If you suggest to define the reference (initial) geometry by using general parallelepiped (instead of axis-aligned box), I would oppose; not that it does not make sense geometrically, but brings quite a bit of complexity where the current facilities are enough. That is what I suggest indeed. Actually, this suggestion came after fixing an obvious mistake in Cell interface, which triggered a code cleaning spree. It would make things simpler and help clarify in the long run, else I would not bother. PBCs and related engines code is excessively complex and overconstrained currently. Removing the axis-aligned constraint makes things more general without adding any complexity. PBCs offer the opportunity of writing (1) frame invariant and (2) shape-independant mechanics by just controlling velGrad and stresses in periodic engines, but this advantage is not really used currently. One reason is the lack of clear split between what is needed/modified for mechanics, for contact detection, and for graphical representation. Overall, mixing all of them results in contaminating the mechanical parts with frame-dependant and (initial)shape-dependant code, which is never a good thing. A few examples : - velGrad is describing a mechanical effect and is reflected in trsf, but at the same time trsf is used to describe the initial geometry. So, it is useless for the user, who has to maintain his own material transformation. Even worst, trsf can be changed for contact detection (flipCell), while this could be hidden away in collider internals. - shearTrsf and friends are not describing shear in the mechanical sense. It is only something that we use for colliding and display, it results in misleading semantic. - refSize is (partialy) describing the initial shape, so it should not influence mechanics at all. Unfortunately, it is used in many places in PeriEngines, it is used to redefine Hsize at each step (not needed), can be modified by users and even by OGLrenderer (?!). It sounds insecure. The suggested change is a small step in the good direction regarding this sort of problems (introducing velGrad and Hsize was on the same line btw). 2. If you need reference (initial) cell that is already deformed, then you can always subtract (in the sense of transformation matrices, i.e. something like A^-1*B*(A^-1)^T) the initial trsf from the current one to get the part that corresponds to material transformation. It would work, but this is the sort of complexity that arbitrary initial shapes would remove. Do you have some concrete scenario in mind? Not saying that it can not exist, but I've never seen the initial sample to be periodic obliquely. Check Jan's scripts (reason why I mentionned him in o.p.)? I do have scenarii too. Also important, it clarifies and help writing frame invariant mechanics. Local diffs pass reg. tests and gives stable stress-strain behaviour starting from non-rectangular box. refSize is not used anywhere, except in OGLRenderer. Functionalities used in existing scripts (refSize=..; trsf=...) are
[Yade-dev] [Branch ~yade-dev/yade/trunk] Rev 2665: update scripts for the WireMatPM
revno: 2665
committer: Klaus Thoeni klaus.tho...@gmail.com
branch nick: yade
timestamp: Thu 2011-01-20 14:45:32 +1100
message:
update scripts for the WireMatPM
renamed:
scripts/test/WIreMatPM/ = scripts/test/WireMatPM/
modified:
scripts/test/WireMatPM/net-2part-displ-unloading.py
scripts/test/WireMatPM/net-2part-displ.py
scripts/test/WireMatPM/net-2part-strain.py
--
lp:yade
https://code.launchpad.net/~yade-dev/yade/trunk
Your team Yade developers is subscribed to branch lp:yade.
To unsubscribe from this branch go to
https://code.launchpad.net/~yade-dev/yade/trunk/+edit-subscription
=== renamed directory 'scripts/test/WIreMatPM' = 'scripts/test/WireMatPM'
=== modified file 'scripts/test/WireMatPM/net-2part-displ-unloading.py'
--- scripts/test/WIreMatPM/net-2part-displ-unloading.py 2010-12-10 02:42:10 +
+++ scripts/test/WireMatPM/net-2part-displ-unloading.py 2011-01-20 03:45:32 +
@@ -53,12 +53,12 @@
def addPlotData():
if O.iter 1:
plot.addData( Fn=0., un=0. )
- plot.saveGnuplot('net-2part-displ-unloading')
+ #plot.saveGnuplot('net-2part-displ-unloading')
else:
try:
i=O.interactions[FixedSphere.id,MovingSphere.id]
plot.addData( Fn=i.phys.normalForce.norm(), un=(O.bodies[1].state.pos[1]-O.bodies[0].state.pos[1])-a )
- plot.saveGnuplot('net-2part-displ-unloading')
+ #plot.saveGnuplot('net-2part-displ-unloading')
except:
print No interaction!
O.pause()
@@ -74,13 +74,14 @@
[Ip2_WireMat_WireMat_WirePhys(linkThresholdIteration=1,label='interactionPhys')],
[Law2_ScGeom_WirePhys_WirePM(linkThresholdIteration=1,label='interactionLaw')]
),
+ NewtonIntegrator(damping=0.),
PyRunner(initRun=True,iterPeriod=1,command='addPlotData()')
]
plot some results
plot.plots={'un':('Fn',)}
-plot.plot()
+plot.plot(noShow=False, subPlots=False)
create link (no time step needed since loading is involved in this step)
=== modified file 'scripts/test/WireMatPM/net-2part-displ.py'
--- scripts/test/WIreMatPM/net-2part-displ.py 2010-12-10 02:42:10 +
+++ scripts/test/WireMatPM/net-2part-displ.py 2011-01-20 03:45:32 +
@@ -35,7 +35,7 @@
create boddies, default: dynamic=True
-O.bodies.append( utils.sphere([0,0,0], radius, wire=False, color=[1,0,0], highlight=False, material=netMat) )
+O.bodies.append( utils.sphere([0,0,0], radius, wire=False, color=[1,0,0], highlight=False, material=netMat, fixed=True) )
O.bodies.append( utils.sphere([0,a,0], radius, wire=False, color=[0,1,0], highlight=False, material=netMat) )
FixedSphere=O.bodies[0]
@@ -49,18 +49,18 @@
def addPlotData():
if O.iter 1:
plot.addData( Fn=0., un=0. )
- plot.saveGnuplot('net-2part-displ')
+ #plot.saveGnuplot('net-2part-displ')
else:
try:
i=O.interactions[FixedSphere.id,MovingSphere.id]
plot.addData( Fn=i.phys.normalForce.norm(), un=(O.bodies[1].state.pos[1]-O.bodies[0].state.pos[1])-a )
- plot.saveGnuplot('net-2part-displ')
+ #plot.saveGnuplot('net-2part-displ')
except:
print No interaction!
O.pause()
- define simulation to create cohesive link
+ define simulation to create link
interactionRadius=2.
O.engines = [
ForceResetter(),
@@ -71,17 +71,18 @@
[Ip2_WireMat_WireMat_WirePhys(linkThresholdIteration=1,label='interactionPhys')],
[Law2_ScGeom_WirePhys_WirePM(linkThresholdIteration=1,label='interactionLaw')]
),
+ NewtonIntegrator(damping=0.),
PyRunner(initRun=True,iterPeriod=1,command='addPlotData()')
]
plot some results
plot.plots={'un':('Fn',)}
-plot.plot()
+plot.plot(noShow=False, subPlots=False)
create link (no time step needed since loading is involved in this step)
-O.step() # create cohesive link (cohesiveTresholdIteration=1)
+O.step() # create link (cohesiveTresholdIteration=1)
initializes now the interaction detection factor
=== modified file 'scripts/test/WireMatPM/net-2part-strain.py'
--- scripts/test/WIreMatPM/net-2part-strain.py 2010-12-10 02:42:10 +
+++ scripts/test/WireMatPM/net-2part-strain.py 2011-01-20 03:45:32 +
@@ -58,7 +58,7 @@
setSpeeds = True
- define simulation to create cohesive link
+ define simulation to create link
interactionRadius=2.
O.engines = [
ForceResetter(),
@@ -69,6 +69,7 @@
[Ip2_WireMat_WireMat_WirePhys(linkThresholdIteration=1,label='interactionPhys')],
[Law2_ScGeom_WirePhys_WirePM(linkThresholdIteration=1,label='interactionLaw')]
),
+ NewtonIntegrator(damping=0.)
]
@@ -90,20 +91,20 @@
from yade import plot
plot.plots={'un':('Fn',)}
-plot.plot()
+plot.plot(noShow=False, subPlots=False)
def addPlotData():
try:
i=O.interactions[FixedSphere.id,MovingSphere.id]
plot.addData( Fn=i.phys.normalForce.norm(), un=(O.bodies[1].state.pos[1]-O.bodies[0].state.pos[1])-a )
- plot.saveGnuplot('net-2part-strain')
+ #plot.saveGnuplot('net-2part-strain')
except:
print No interaction!
O.pause()
define simulation
-O.engines +=
[Yade-dev] Last changes
Hi guys! A lot of changes have been done in the last few weeks. I just tried to run some scripts and I ended up with some troubles. Somehow I fixed my scripts for the WireMatPM but I couldn't really understand why I needed this changes. Someone can explain it to me please? Some other scripts I tried to run and give problems are: scripts/test/mindlin.py scripts/normalInelasticity-test.py Some problems seem to be related to matplotlib, e.g. in my scripts the default values for plot.plot() have not been accepted and the legend in the live plot has additional names as shown in the attachments (collection0...n). However, I couldn't find out why for my tests Renderer().intrAllWire=True is not showing the interaction any more. Any idea? Thanks Klaus attachment: image.png___ 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] Another stress in bodies
Hi,
Have a look to this paper: http://www.springerlink.com/content/l133vr26m7142101/
I can send you the pdf if necessary.
The stress computation at particle level is explained in section 5. Basically,
it correspond from the dimensional point of view to the moment tensor divided
by a volume. The volume can be chosen so that the sum of all particle-stress
equal to the global stress. In Eq. 14, I assumed a homogeneous solid fraction
('compacité' in French), but this assumption can be avoided by using the
voronoi-cell volumes...
Another think: I believe we can not talk about exact mean stress tensor at
the particle level since the local volume is not well definable.
Vincent
Le 17 janv. 2011 à 20:43, Anton Gladky a écrit :
Thanks, Bruno!
I will have a look at this, but, please, do not delete the previous function,
it is used in VTKRecorder.
Anton
On Mon, Jan 17, 2011 at 6:44 PM, Bruno Chareyre bruno.chare...@hmg.inpg.fr
wrote:
XLatexIt! run report...
*** Found expression $$\sigma_{ij}^{macro}/compacity$$
Image was already generated
*** Found expression $$\int_V s_{ij}dV = \int_{S_V} x_i.s_{ij}.n_j.dS =
\sum_kx_i^k.f_j^k$$
Hi,
I've been adding another definition of stress in particles (not adapted to
periodic BCs yet, though not difficult).
For those interested. The documentation is pasted below.
_
Compute the exact mean stress tensor in each sphere from the contour integral
of applied load.
After divergence theorem, at equilibrium:
tblatex-11.png.
This relation applies for arbitrary shapes but the result has to be divided
by the solid's volume, computed here using the radii, hence assuming spheres.
The (weighted) average of per-body stresses is exactly equal to the average
stress in the solid phase, i.e. tblatex-8.png.
_
Cheers.
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
___
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
