[Yade-dev] [Bug 1813782] [NEW] Repeated plot.plot() fail
Public bug reported:
Hi there,
Since bugs report get a lot of attention these days :-) let me add
another one:
###
from yade import plot
plot.addData(x = 1 , y = 5)
plot.plots = {'x':'y'}
plot.plot()
plot.plot()
###
gives error messages (pointing to py/plot.py, see [*] below) at the
second plot.plot() command.
It seems you can also replace any of the 2 plot.plot() (or both) with eg
plot.plot(noShow=True).savefig('test.png') and get the same behavior.
I would prefer having the possibility to ask twice for a plot in one
YADE session, what do you think ?
[*] Error message with yadedaily 2018.02b-290bf6a54e~bionic or yade
2018.02b:
AttributeErrorTraceback (most recent call last)
/usr/bin/yadedaily in ()
> 1 plot.plot()
/usr/lib/x86_64-linux-gnu/yadedaily/py/yade/plot.py in plot(noShow, subPlots)
592 .. note:: For backwards compatibility reasons, *noShow* option
will return list of figures for multiple figures but a single figure (rather
than list with 1 element) if there is only 1 figure.
593 """
--> 594 createPlots(subPlots=subPlots)
595 global currLineRefs
596 figs=set([l.line.axes.get_figure() for l in currLineRefs])
/usr/lib/x86_64-linux-gnu/yadedaily/py/yade/plot.py in createPlots(subPlots,
scatterSize, wider)
370 def createPlots(subPlots=True,scatterSize=60,wider=False):
371 global currLineRefs
--> 372 figs=set([l.line.get_axes().get_figure() for l in
currLineRefs]) # get all current figures
373 for f in figs: pylab.close(f) # close those
374 currLineRefs=[] # remove older plots (breaks live updates of
windows that are still open)
AttributeError: 'Line2D' object has no attribute 'get_axes'
##
** Affects: yade
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1813782
Title:
Repeated plot.plot() fail
Status in Yade:
New
Bug description:
Hi there,
Since bugs report get a lot of attention these days :-) let me add
another one:
###
from yade import plot
plot.addData(x = 1 , y = 5)
plot.plots = {'x':'y'}
plot.plot()
plot.plot()
###
gives error messages (pointing to py/plot.py, see [*] below) at the
second plot.plot() command.
It seems you can also replace any of the 2 plot.plot() (or both) with
eg plot.plot(noShow=True).savefig('test.png') and get the same
behavior.
I would prefer having the possibility to ask twice for a plot in one
YADE session, what do you think ?
[*] Error message with yadedaily 2018.02b-290bf6a54e~bionic or yade
2018.02b:
AttributeErrorTraceback (most recent call last)
/usr/bin/yadedaily in ()
> 1 plot.plot()
/usr/lib/x86_64-linux-gnu/yadedaily/py/yade/plot.py in plot(noShow, subPlots)
592 .. note:: For backwards compatibility reasons, *noShow*
option will return list of figures for multiple figures but a single figure
(rather than list with 1 element) if there is only 1 figure.
593 """
--> 594 createPlots(subPlots=subPlots)
595 global currLineRefs
596 figs=set([l.line.axes.get_figure() for l in currLineRefs])
/usr/lib/x86_64-linux-gnu/yadedaily/py/yade/plot.py in createPlots(subPlots,
scatterSize, wider)
370 def createPlots(subPlots=True,scatterSize=60,wider=False):
371 global currLineRefs
--> 372 figs=set([l.line.get_axes().get_figure() for l in
currLineRefs]) # get all current figures
373 for f in figs: pylab.close(f) # close those
374 currLineRefs=[] # remove older plots (breaks live updates of
windows that are still open)
AttributeError: 'Line2D' object has no attribute 'get_axes'
##
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1813782/+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
[Yade-dev] [Bug 1810283] Re: Wiki homepage broken
Back to normal, indeed... Closing, thanks Robert. ** Changed in: yade Status: New => Invalid -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1810283 Title: Wiki homepage broken Status in Yade: Invalid Bug description: For the record, https://www.yade-dem.org/wiki/Yade currently just outputs here: *** Database error From Yade A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SqlBagOStuff::set". Database returned error "1114: The table 'yade_objectcache' is full (localhost)". *** No idea whether it's a problem on wikimedia's, or our side ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1810283/+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
[Yade-dev] [Bug 1810283] [NEW] Wiki homepage broken
Public bug reported: For the record, https://www.yade-dem.org/wiki/Yade currently just outputs here: *** Database error >From Yade A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SqlBagOStuff::set". Database returned error "1114: The table 'yade_objectcache' is full (localhost)". *** No idea whether it's a problem on wikimedia's, or our side ? ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1810283 Title: Wiki homepage broken Status in Yade: New Bug description: For the record, https://www.yade-dem.org/wiki/Yade currently just outputs here: *** Database error From Yade A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SqlBagOStuff::set". Database returned error "1114: The table 'yade_objectcache' is full (localhost)". *** No idea whether it's a problem on wikimedia's, or our side ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1810283/+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
[Yade-dev] [Bug 1804621] Re: bodyNumInteractionsHistogram broken
The fact is py/pack/_packPredicates.cpp defines aabb() functions for predicates that still return tuples (not lists, as I proposed). I do not think this would necessarily conflict with the use of list in aabbExtrema(), but I still can not say I know all of _packPredicates.cpp Then, in terms of a manual search for problems in pack-related scripts, I for instance tested: examples/gts-horse/gts-operators.py examples/gts-horse/gts-random-pack-obb.py examples/test/pack-cloud.py examples/test/pack-predicates.py examples/packs/packs.py examples/gts-horse/gts-horse.py examples/WireMatPM/wirepackings.py which all worked well. Other scripts showed a possibly more problematic behavior examples/gts-horse/gts-random-pack.py => pkg/common/Facet.cpp:26 postLoad: Facet has coincident vertices 2 (0 -0 -0) and 0 (0 -0 -0)! examples/polyhedra/horse.py => RuntimeWarning: No spheres are produced by regularHexa-function examples/stl-gts/gts-stl.py => ZeroDivisionError: float division by zero in regularHexa I actually tested these scripts with three different versions of the executable: - Yade 1.20.0 (yade package: aabbExtrema() is a tuple) - current trunk after #2 ie commit 7c60d78 (aabbExtrema() is a list, after the previous "suspicious" commit) - and commit 7c60d78 + the patch from #8 (aabbExtrema() is a tuple again). The above possibly more problematic behaviors were always present in these three cases, suggesting they do not relate at all with the present "bug"... (hence my comment in #8) Let me know in case you have further remarks. -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1804621 Title: bodyNumInteractionsHistogram broken Status in Yade: New Bug description: See https://answers.launchpad.net/yade/+question/676284 and: # O.bodies.append(sphere((0,0,0),1,dynamic=False)) O.bodies.append(sphere((0,0,1.9),1,dynamic=False)) O.step() print 'BodyNumInteractions Histogram', bodyNumInteractionsHistogram(aabbExtrema()) which returns (with trunk version) : ArgumentError: Python argument types in yade._utils.bodyNumInteractionsHistogram(list) did not match C++ signature: bodyNumInteractionsHistogram(boost::python::tuple aabb, bool contactOnly=False) because my commit [*] changed the Python return type of aabbExtrema() from tuple to list. Possible (and easiest) fix would be to change all corresponding py::tuple aabb from py::list aabb. Agree ? Or do we want this function to deal with Python tuples and not lists ?.. Jérôme [*] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1804621/+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
[Yade-dev] [Bug 1804621] Re: bodyNumInteractionsHistogram broken
For the record, I'm herein attaching a patch that would make aabbExtrema() back to a tuple, cancelling the effects of commits 1db13fb ( = [*] in the bug report) and 7c60d78 ( = more recent commit mentioned in #2) As of now, I do not think this patch should be applied, see other comments regarding the (lack of) detected problems ** Patch added: "patch.diff" https://bugs.launchpad.net/yade/+bug/1804621/+attachment/5216535/+files/patch.diff -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1804621 Title: bodyNumInteractionsHistogram broken Status in Yade: New Bug description: See https://answers.launchpad.net/yade/+question/676284 and: # O.bodies.append(sphere((0,0,0),1,dynamic=False)) O.bodies.append(sphere((0,0,1.9),1,dynamic=False)) O.step() print 'BodyNumInteractions Histogram', bodyNumInteractionsHistogram(aabbExtrema()) which returns (with trunk version) : ArgumentError: Python argument types in yade._utils.bodyNumInteractionsHistogram(list) did not match C++ signature: bodyNumInteractionsHistogram(boost::python::tuple aabb, bool contactOnly=False) because my commit [*] changed the Python return type of aabbExtrema() from tuple to list. Possible (and easiest) fix would be to change all corresponding py::tuple aabb from py::list aabb. Agree ? Or do we want this function to deal with Python tuples and not lists ?.. Jérôme [*] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1804621/+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
[Yade-dev] [Bug 1804621] Re: bodyNumInteractionsHistogram broken
I'll try to avoid exaggeration here. My commit [1] was about a Shop / utils function, maybe not exactly a bottom layer of yade (at least, not in my opinion). As illustrated by the present bug and the launchpad question, [1] could be problematic in case of Python code (hardcoded in trunk or in users scripts) involving some other functions exposed through boost python with a specific type of arguments. It is true I did not foresee this problem in [1], in spite of the discussion [2] (see also therein for the motivations to commit [1]) As for #4 and Robert's list #1, I went through it and do not think there is now (was ?) any problem in this list due to commit [1], and in possible connection with the present bug. I will look closely into py/pack/_packPredicates. [1] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 [2] https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13339.html, fourth item in particular... -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1804621 Title: bodyNumInteractionsHistogram broken Status in Yade: New Bug description: See https://answers.launchpad.net/yade/+question/676284 and: # O.bodies.append(sphere((0,0,0),1,dynamic=False)) O.bodies.append(sphere((0,0,1.9),1,dynamic=False)) O.step() print 'BodyNumInteractions Histogram', bodyNumInteractionsHistogram(aabbExtrema()) which returns (with trunk version) : ArgumentError: Python argument types in yade._utils.bodyNumInteractionsHistogram(list) did not match C++ signature: bodyNumInteractionsHistogram(boost::python::tuple aabb, bool contactOnly=False) because my commit [*] changed the Python return type of aabbExtrema() from tuple to list. Possible (and easiest) fix would be to change all corresponding py::tuple aabb from py::list aabb. Agree ? Or do we want this function to deal with Python tuples and not lists ?.. Jérôme [*] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1804621/+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
[Yade-dev] [Bug 1804621] Re: bodyNumInteractionsHistogram broken
See commit https://github.com/yade/trunk/commit/7c60d78bd9badfa174fb79a82af7b119abf81d5d. It fixes the example in the above and the related Launchpad question (I guess, since there was no MWE therein ;-) ). There are also several uses of aabb tuple stuff in /py/pack/_packPredicates.cpp which is untouched for now and requires more time to be looked at. It is not mandatory things are broken there. -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1804621 Title: bodyNumInteractionsHistogram broken Status in Yade: New Bug description: See https://answers.launchpad.net/yade/+question/676284 and: # O.bodies.append(sphere((0,0,0),1,dynamic=False)) O.bodies.append(sphere((0,0,1.9),1,dynamic=False)) O.step() print 'BodyNumInteractions Histogram', bodyNumInteractionsHistogram(aabbExtrema()) which returns (with trunk version) : ArgumentError: Python argument types in yade._utils.bodyNumInteractionsHistogram(list) did not match C++ signature: bodyNumInteractionsHistogram(boost::python::tuple aabb, bool contactOnly=False) because my commit [*] changed the Python return type of aabbExtrema() from tuple to list. Possible (and easiest) fix would be to change all corresponding py::tuple aabb from py::list aabb. Agree ? Or do we want this function to deal with Python tuples and not lists ?.. Jérôme [*] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1804621/+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
[Yade-dev] [Bug 1804621] Re: bodyNumInteractionsHistogram broken
** Changed in: yade Assignee: (unassigned) => Jérôme Duriez (jduriez) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1804621 Title: bodyNumInteractionsHistogram broken Status in Yade: New Bug description: See https://answers.launchpad.net/yade/+question/676284 and: # O.bodies.append(sphere((0,0,0),1,dynamic=False)) O.bodies.append(sphere((0,0,1.9),1,dynamic=False)) O.step() print 'BodyNumInteractions Histogram', bodyNumInteractionsHistogram(aabbExtrema()) which returns (with trunk version) : ArgumentError: Python argument types in yade._utils.bodyNumInteractionsHistogram(list) did not match C++ signature: bodyNumInteractionsHistogram(boost::python::tuple aabb, bool contactOnly=False) because my commit [*] changed the Python return type of aabbExtrema() from tuple to list. Possible (and easiest) fix would be to change all corresponding py::tuple aabb from py::list aabb. Agree ? Or do we want this function to deal with Python tuples and not lists ?.. Jérôme [*] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1804621/+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
[Yade-dev] [Bug 1804621] [NEW] bodyNumInteractionsHistogram broken
Public bug reported: See https://answers.launchpad.net/yade/+question/676284 and: # O.bodies.append(sphere((0,0,0),1,dynamic=False)) O.bodies.append(sphere((0,0,1.9),1,dynamic=False)) O.step() print 'BodyNumInteractions Histogram', bodyNumInteractionsHistogram(aabbExtrema()) which returns (with trunk version) : ArgumentError: Python argument types in yade._utils.bodyNumInteractionsHistogram(list) did not match C++ signature: bodyNumInteractionsHistogram(boost::python::tuple aabb, bool contactOnly=False) because my commit [*] changed the Python return type of aabbExtrema() from tuple to list. Possible (and easiest) fix would be to change all corresponding py::tuple aabb from py::list aabb. Agree ? Or do we want this function to deal with Python tuples and not lists ?.. Jérôme [*] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1804621 Title: bodyNumInteractionsHistogram broken Status in Yade: New Bug description: See https://answers.launchpad.net/yade/+question/676284 and: # O.bodies.append(sphere((0,0,0),1,dynamic=False)) O.bodies.append(sphere((0,0,1.9),1,dynamic=False)) O.step() print 'BodyNumInteractions Histogram', bodyNumInteractionsHistogram(aabbExtrema()) which returns (with trunk version) : ArgumentError: Python argument types in yade._utils.bodyNumInteractionsHistogram(list) did not match C++ signature: bodyNumInteractionsHistogram(boost::python::tuple aabb, bool contactOnly=False) because my commit [*] changed the Python return type of aabbExtrema() from tuple to list. Possible (and easiest) fix would be to change all corresponding py::tuple aabb from py::list aabb. Agree ? Or do we want this function to deal with Python tuples and not lists ?.. Jérôme [*] https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1804621/+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
[Yade-dev] [Bug 1794479] [NEW] PeriTriaxController doc
Public bug reported: Doc [*] mentions a not-existing strainStress attribute, instead of goal. For the record and later fix (unless someone does it before me) [*] https://yade- dem.org/doc/yade.wrapper.html#yade.wrapper.PeriTriaxController ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1794479 Title: PeriTriaxController doc Status in Yade: New Bug description: Doc [*] mentions a not-existing strainStress attribute, instead of goal. For the record and later fix (unless someone does it before me) [*] https://yade- dem.org/doc/yade.wrapper.html#yade.wrapper.PeriTriaxController To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1794479/+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
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
Initial MeasureCapStress problem fixed in commit 68b0557. The possible use of e.g. boost::python::extract during Engine::action() (see the link in #3) remains to be explored, as far as I'm concerned. ** Changed in: yade Status: New => Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: Fix Released Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+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
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
For the record, see also https://www.mail-archive.com/yade- d...@lists.launchpad.net/msg13223.html -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+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
[Yade-dev] [Bug 1774065] Re: doctests fail with numpy 1.14
I have numpy 1.11.0 actually
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1774065
Title:
doctests fail with numpy 1.14
Status in Yade:
New
Status in Debian:
Confirmed
Bug description:
==
FAIL: saveDataTxt (yade.plot)
Doctest: yade.plot.saveDataTxt
--
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 2226, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for yade.plot.saveDataTxt
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 614, in
saveDataTxt
--
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 626, in
yade.plot.saveDataTxt
Failed example:
d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
File "", line 1, in
d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
File "/usr/lib/python2.7/dist-packages/numpy/lib/npyio.py", line 1689,
in genfromtxt
fhd = iter(np.lib._datasource.open(fname, 'rt', encoding=encoding))
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line
260, in open
return ds.open(path, mode, encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line
614, in open
encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line
88, in _python2_bz2open
raise ValueError("bz2 text files not supported in python2")
ValueError: bz2 text files not supported in python2
--
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 627, in
yade.plot.saveDataTxt
Failed example:
d['a']
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
File "", line 1, in
d['a']
NameError: name 'd' is not defined
--
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 629, in
yade.plot.saveDataTxt
Failed example:
d['b']
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
File "", line 1, in
d['b']
NameError: name 'd' is not defined
--
Ran 58 tests in 1.063s
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1774065/+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
[Yade-dev] [Bug 1774065] Re: doctests fail with numpy 1.14
I do not confirm it:
jerome.duriez@AXP17003:~$ yadedaily
Welcome to Yade 2018.02b-1270674828~xenial
TCP python prompt on localhost:9000, auth cookie `dckayu'
XMLRPC info provider on http://localhost:21000
[[ ^L clears screen, ^U kills line. F12 controller, F11 3d view (use h-key for
showing help), F10 both, F9 generator, F8 plot. ]]
Yade [1]: from yade import plot
Yade [2]: plot.reset()
Yade [3]: plot.addData(a=1,b=11,c=21,d=31) # add some data here
Yade [4]: plot.saveDataTxt('/tmp/dataFile.txt.bz2',vars=('a','b','c'))
Yade [5]: import numpy
Yade [6]:
d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
Yade [7]: d
-> [7]:
array((1, 11, 21),
dtype=[('a', 'https://bugs.launchpad.net/bugs/1774065
Title:
doctests fail with numpy 1.14
Status in Yade:
New
Status in Debian:
Confirmed
Bug description:
==
FAIL: saveDataTxt (yade.plot)
Doctest: yade.plot.saveDataTxt
--
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 2226, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for yade.plot.saveDataTxt
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 614, in
saveDataTxt
--
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 626, in
yade.plot.saveDataTxt
Failed example:
d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
File "", line 1, in
d=numpy.genfromtxt('/tmp/dataFile.txt.bz2',dtype=None,names=True)
File "/usr/lib/python2.7/dist-packages/numpy/lib/npyio.py", line 1689,
in genfromtxt
fhd = iter(np.lib._datasource.open(fname, 'rt', encoding=encoding))
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line
260, in open
return ds.open(path, mode, encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line
614, in open
encoding=encoding, newline=newline)
File "/usr/lib/python2.7/dist-packages/numpy/lib/_datasource.py", line
88, in _python2_bz2open
raise ValueError("bz2 text files not supported in python2")
ValueError: bz2 text files not supported in python2
--
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 627, in
yade.plot.saveDataTxt
Failed example:
d['a']
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
File "", line 1, in
d['a']
NameError: name 'd' is not defined
--
File "/usr/lib/x86_64-linux-gnu/yade/py/yade/plot.py", line 629, in
yade.plot.saveDataTxt
Failed example:
d['b']
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python2.7/doctest.py", line 1315, in __run
compileflags, 1) in test.globs
File "", line 1, in
d['b']
NameError: name 'd' is not defined
--
Ran 58 tests in 1.063s
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1774065/+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
[Yade-dev] [Bug 1773337] Re: Doc section "Debian packaging instructions" obsolete
Fixed in https://github.com/yade/trunk/commit/87144ecc6964ceac3995928198f62c3982a5b15f, thanks for feedback Anton. ** Changed in: yade Status: New => Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1773337 Title: Doc section "Debian packaging instructions" obsolete Status in Yade: Fix Released Bug description: Hi, The https://yade-dem.org/doc/prog.html#debian-packaging-instructions section seems to me obsolete. 1. For sure, all links in https://yade-dem.org/doc/prog.html#prepare-source-package are broken. They actually direct to some trunk folder which has been first moved [1], then simply removed [2]. YADE-specific links in https://yade-dem.org/doc/prog.html#create-binary-package are also broken 2. By the way, is it actually still possible to have different packages for different YADE versions ? (or do we just have yadedaily and yade packages ?) And can any of these instructions still be used ? FIX proposal Remove everything from https://yade-dem.org/doc/prog.html#debian- packaging-instructions :-) and essentially mention that YADE packaging is done according to https://github.com/yade/yadedaily files ? (Depending on the answer to 2.) Jérôme [1] https://github.com/yade/trunk/commit/31f3b16394f7b2801e3e015544e96215bf98ae3d [2] https://github.com/yade/trunk/commit/cc91b709a1a0529d5a0618bf7bbbd58a8a1bc720 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1773337/+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
[Yade-dev] [Bug 1773337] [NEW] Doc section "Debian packaging instructions" obsolete
Public bug reported: Hi, The https://yade-dem.org/doc/prog.html#debian-packaging-instructions section seems to me obsolete. 1. For sure, all links in https://yade-dem.org/doc/prog.html#prepare-source-package are broken. They actually direct to some trunk folder which has been first moved [1], then simply removed [2]. YADE-specific links in https://yade-dem.org/doc/prog.html#create-binary-package are also broken 2. By the way, is it actually still possible to have different packages for different YADE versions ? (or do we just have yadedaily and yade packages ?) And can any of these instructions still be used ? FIX proposal Remove everything from https://yade-dem.org/doc/prog.html#debian- packaging-instructions :-) and essentially mention that YADE packaging is done according to https://github.com/yade/yadedaily files ? (Depending on the answer to 2.) Jérôme [1] https://github.com/yade/trunk/commit/31f3b16394f7b2801e3e015544e96215bf98ae3d [2] https://github.com/yade/trunk/commit/cc91b709a1a0529d5a0618bf7bbbd58a8a1bc720 ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1773337 Title: Doc section "Debian packaging instructions" obsolete Status in Yade: New Bug description: Hi, The https://yade-dem.org/doc/prog.html#debian-packaging-instructions section seems to me obsolete. 1. For sure, all links in https://yade-dem.org/doc/prog.html#prepare-source-package are broken. They actually direct to some trunk folder which has been first moved [1], then simply removed [2]. YADE-specific links in https://yade-dem.org/doc/prog.html#create-binary-package are also broken 2. By the way, is it actually still possible to have different packages for different YADE versions ? (or do we just have yadedaily and yade packages ?) And can any of these instructions still be used ? FIX proposal Remove everything from https://yade-dem.org/doc/prog.html#debian- packaging-instructions :-) and essentially mention that YADE packaging is done according to https://github.com/yade/yadedaily files ? (Depending on the answer to 2.) Jérôme [1] https://github.com/yade/trunk/commit/31f3b16394f7b2801e3e015544e96215bf98ae3d [2] https://github.com/yade/trunk/commit/cc91b709a1a0529d5a0618bf7bbbd58a8a1bc720 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1773337/+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
[Yade-dev] [Bug 1378717] Re: Error in sphinx output + "make doc" failure on buildbot
See also https://bugs.launchpad.net/yade/+bug/1455621, comment #1 at least ? ** Changed in: yade Status: New => Confirmed -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1378717 Title: Error in sphinx output + "make doc" failure on buildbot Status in Yade: Confirmed Bug description: See this question: https://answers.launchpad.net/yade/+question/255486 Some import issues. I also get some when running yadeSphinx.py locally on ubuntu 12.04. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1378717/+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
[Yade-dev] [Bug 1455621] Re: documentation bug: getting class name fails
For comment #1 at least, see also https://bugs.launchpad.net/yade/+bug/1378717 ? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1455621 Title: documentation bug: getting class name fails Status in Yade: New Bug description: In the example code of section [1], class.name fails. I couldn't find the solution myself, still searching... [1] https://yade-dem.org/doc/prog.html?highlight=classname#run-time- type-identification-rtti To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1455621/+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
[Yade-dev] [Bug 1767601] Re: segmentation fault after erasing some particles
Hi, If it now works while it used not to, I think we can say it's fixed ;-) A recently updated yadedaily should indeed reflect the above-mentioned commit https://github.com/yade/trunk/commit/bd1089e77eae83c41c4ce0c60873e1e234ba9c89 (the compilation problems I mentioned in #3 are solved now --- and, actually, they never affected yadedaily packages anyway) Enjoy, Jérôme -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1767601 Title: segmentation fault after erasing some particles Status in Yade: Fix Released Bug description: Dear all, I built a simple script according to script-session1.py (B.Chareyre). I tried to erase some particles, it was done without any problem. but after finishing the simulation, as soon as I tried to run more iterations, it showed segmentation fault and quit yade. The length of O.bodies is similar to The one before erasing.(Does not change after erasing) you can see my question in: https://answers.launchpad.net/yade/+question/668274 I'm using Ubuntu 14.04 LTS and yadedaily version: 2018.02b-85-f861843~trusty And here is my script: # -*- coding: utf-8 -*- from yade import pack, plot young=1e8 compFricDegree = 5 finalFricDegree = 35 mn,mx=Vector3(0,0,0),Vector3(.005,.005,.005) 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) psdSizes=[.1,.6,.8,.0002,.0004,.0005,.0008,.001] psdCumm=[0,.0175,.025,.4,.5,.7,.85,1] sp=pack.SpherePack() sp.makeCloud(mn,mx,psdSizes=psdSizes,psdCumm=psdCumm,distributeMass=True,num=500) sp.toSimulation(material='spheres') triax=TriaxialStressController( maxMultiplier=1.001, finalMaxMultiplier=1.0001, thickness = 0, stressMask = 7, internalCompaction=True, ) 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" ), triax, newton, ] O.dt=PWaveTimeStep() triax.goal1=triax.goal2=triax.goal3=-1 while 1: O.run(1000,True) unb=unbalancedForce() print 'porosity', triax.porosity if unb<0.01 and abs(-1-triax.meanStress)/1<.01: break bodiesToBeDeleted=[] for b in O.bodies: if b.id in range(6): continue else: if b.state.pos[0]<.002: bodiesToBeDeleted.append(b) for b in bodiesToBeDeleted: O.bodies.erase(b.id) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1767601/+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
[Yade-dev] [Bug 1767601] Re: segmentation fault after erasing some particles
For playing with source code, you may refer to https://yade- dem.org/doc/installation.html#source-code for source code download and compilation (i.e. YADE installation), then the Programmer's manual https ://yade-dem.org/doc/prog.html. -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1767601 Title: segmentation fault after erasing some particles Status in Yade: Fix Released Bug description: Dear all, I built a simple script according to script-session1.py (B.Chareyre). I tried to erase some particles, it was done without any problem. but after finishing the simulation, as soon as I tried to run more iterations, it showed segmentation fault and quit yade. The length of O.bodies is similar to The one before erasing.(Does not change after erasing) you can see my question in: https://answers.launchpad.net/yade/+question/668274 I'm using Ubuntu 14.04 LTS and yadedaily version: 2018.02b-85-f861843~trusty And here is my script: # -*- coding: utf-8 -*- from yade import pack, plot young=1e8 compFricDegree = 5 finalFricDegree = 35 mn,mx=Vector3(0,0,0),Vector3(.005,.005,.005) 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) psdSizes=[.1,.6,.8,.0002,.0004,.0005,.0008,.001] psdCumm=[0,.0175,.025,.4,.5,.7,.85,1] sp=pack.SpherePack() sp.makeCloud(mn,mx,psdSizes=psdSizes,psdCumm=psdCumm,distributeMass=True,num=500) sp.toSimulation(material='spheres') triax=TriaxialStressController( maxMultiplier=1.001, finalMaxMultiplier=1.0001, thickness = 0, stressMask = 7, internalCompaction=True, ) 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" ), triax, newton, ] O.dt=PWaveTimeStep() triax.goal1=triax.goal2=triax.goal3=-1 while 1: O.run(1000,True) unb=unbalancedForce() print 'porosity', triax.porosity if unb<0.01 and abs(-1-triax.meanStress)/1<.01: break bodiesToBeDeleted=[] for b in O.bodies: if b.id in range(6): continue else: if b.state.pos[0]<.002: bodiesToBeDeleted.append(b) for b in bodiesToBeDeleted: O.bodies.erase(b.id) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1767601/+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
[Yade-dev] [Bug 1767601] Re: segmentation fault after erasing some particles
Thanks, I could reproduce the crash with this script. Solution The change [1] should fix your problems. Obviously you need to update your yade version to enjoy this change. In terms of package versions, I do not know when this change will be reflected in yadedaily, considering in particular we currently have compiling problems. [2] If you use a local source code version, the best is for you to apply locally the same change as [1] (and to recompile.. :-) ) Reason ** As told by Jan in the Launchpad question thread, the bug came from growParticles() where interactions operations were performed before checking whether the interaction actually is real. Because these soon- to-be-erased interactions (involving deleted bodies) were accessed, deleted bodies, were tried to be accessed as well, leading to the crash. Advice ** The MWE below was enough to trigger the exact same bug: - O.bodies.append(sphere(Vector3(0,0,0),1)) O.bodies.append(sphere(Vector3(0,0,2),1)) O.step() O.bodies.erase(1) growParticles(1.5) - and would have maybe (??) led to a faster bug resolution, enticing more people to look faster at the issue. I understand showing real MWE may require some YADE practice.. Nevertheless, it's worth trying it, and here you had some elements from Jan narrowing down the problem to Shop::growParticles() This being said, I just hope this will motivate you to dig into the source code, happy YADE-ing ! ;-) [1] https://github.com/yade/trunk/commit/bd1089e77eae83c41c4ce0c60873e1e234ba9c89 [2] https://yade-dem.org/buildbot/one_line_per_build ** Changed in: yade Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1767601 Title: segmentation fault after erasing some particles Status in Yade: Fix Released Bug description: Dear all, I built a simple script according to script-session1.py (B.Chareyre). I tried to erase some particles, it was done without any problem. but after finishing the simulation, as soon as I tried to run more iterations, it showed segmentation fault and quit yade. The length of O.bodies is similar to The one before erasing.(Does not change after erasing) you can see my question in: https://answers.launchpad.net/yade/+question/668274 I'm using Ubuntu 14.04 LTS and yadedaily version: 2018.02b-85-f861843~trusty And here is my script: # -*- coding: utf-8 -*- from yade import pack, plot young=1e8 compFricDegree = 5 finalFricDegree = 35 mn,mx=Vector3(0,0,0),Vector3(.005,.005,.005) 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) psdSizes=[.1,.6,.8,.0002,.0004,.0005,.0008,.001] psdCumm=[0,.0175,.025,.4,.5,.7,.85,1] sp=pack.SpherePack() sp.makeCloud(mn,mx,psdSizes=psdSizes,psdCumm=psdCumm,distributeMass=True,num=500) sp.toSimulation(material='spheres') triax=TriaxialStressController( maxMultiplier=1.001, finalMaxMultiplier=1.0001, thickness = 0, stressMask = 7, internalCompaction=True, ) 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" ), triax, newton, ] O.dt=PWaveTimeStep() triax.goal1=triax.goal2=triax.goal3=-1 while 1: O.run(1000,True) unb=unbalancedForce() print 'porosity', triax.porosity if unb<0.01 and abs(-1-triax.meanStress)/1<.01: break bodiesToBeDeleted=[] for b in O.bodies: if b.id in range(6): continue else: if b.state.pos[0]<.002: bodiesToBeDeleted.append(b) for b in bodiesToBeDeleted: O.bodies.erase(b.id) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1767601/+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
[Yade-dev] [Bug 1767601] Re: segmentation fault after erasing some particles
** Changed in: yade Assignee: (unassigned) => Jérôme Duriez (jduriez) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1767601 Title: segmentation fault after erasing some particles Status in Yade: Incomplete Bug description: Dear all, I built a simple script according to script-session1.py (B.Chareyre). I tried to erase some particles, it was done without any problem. but after finishing the simulation, as soon as I tried to run more iterations, it showed segmentation fault and quit yade. The length of O.bodies is similar to The one before erasing.(Does not change after erasing) you can see my question in: https://answers.launchpad.net/yade/+question/668274 I'm using Ubuntu 14.04 LTS and yadedaily version: 2018.02b-85-f861843~trusty And here is my script: # -*- coding: utf-8 -*- from yade import pack, plot young=1e8 compFricDegree = 5 finalFricDegree = 35 mn,mx=Vector3(0,0,0),Vector3(.005,.005,.005) 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) psdSizes=[.1,.6,.8,.0002,.0004,.0005,.0008,.001] psdCumm=[0,.0175,.025,.4,.5,.7,.85,1] sp=pack.SpherePack() sp.makeCloud(mn,mx,psdSizes=psdSizes,psdCumm=psdCumm,distributeMass=True,num=500) sp.toSimulation(material='spheres') triax=TriaxialStressController( maxMultiplier=1.001, finalMaxMultiplier=1.0001, thickness = 0, stressMask = 7, internalCompaction=True, ) 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" ), triax, newton, ] O.dt=PWaveTimeStep() triax.goal1=triax.goal2=triax.goal3=-1 while 1: O.run(1000,True) unb=unbalancedForce() print 'porosity', triax.porosity if unb<0.01 and abs(-1-triax.meanStress)/1<.01: break bodiesToBeDeleted=[] for b in O.bodies: if b.id in range(6): continue else: if b.state.pos[0]<.002: bodiesToBeDeleted.append(b) for b in bodiesToBeDeleted: O.bodies.erase(b.id) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1767601/+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
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
Hi, Thank you very much Bruno for the links and hints, I understand there probably is some bad practice here (see 3.). 1. However, I'm quite sure the crash is just caused by the following line "boost::python::tuple extrema = Shop::aabbExtrema();" [1] I thus suspect incorrect Python/C++ extraction or items access are not the reason of the present crash ? 2. Actually, I would like to point out the following "funny" fact: 2.1. Asking ** O.run(100,True) # => crash ** at the end of the above MWE triggers (in one call to MeasureCapStress) the crash. (same with O.run()) 2.2. Asking ** for i in range(0,100): O.step() # => no crash ** instead of O.run does not trigger any crash. The ~100 calls to MeasureCapStress pass like a charm.. 3. The syntax I used in this MeasureCapStress code was directly inspired from what is done in getPorosity() [2], getStress() [3], or fabricTensor() [4] utils functions (which work, I guess). It's true none of those was probably intended to be used "within" the simulation loop, though.. Thanks, Jérôme [1] if you would just add this line in NewtonIntegrator::action() (with the correct "include"), same kind of segfaults would occur [2] https://github.com/yade/trunk/blob/d504abfec35f13e8b7e58ba3f59e5014c6196531/pkg/dem/Shop_01.cpp#L304 [3] https://github.com/yade/trunk/blob/c8be93791ffbc99b0e63275c1b866414391b27c0/pkg/dem/Shop_02.cpp#L352 [4] https://github.com/yade/trunk/blob/c8be93791ffbc99b0e63275c1b866414391b27c0/pkg/dem/Shop_02.cpp#L266 -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+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
[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop
** Summary changed: - MeasureCapStress-caused segmentation fault (boost::python) + Segfaults with boost::python::tuple during simulation loop -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: Segfaults with boost::python::tuple during simulation loop Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1764424/+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
[Yade-dev] [Bug 1767601] Re: segmentation fault after erasing some particles
Hi, I launched this script with Yade 2018-04-19.git-79b2edb. I got the repeated output of "porosity X" with the porosity X-value soon getting negativ, and then decreasing againt until ~ -1e100, then I stopped manually the simulation. I did not get any segmentation fault. Could you clarify the situation, please ? ** Changed in: yade Status: New => Incomplete -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1767601 Title: segmentation fault after erasing some particles Status in Yade: Incomplete Bug description: Dear all, I built a simple script according to script-session1.py (B.Chareyre). I tried to erase some particles, it was done without any problem. but after finishing the simulation, as soon as I tried to run more iterations, it showed segmentation fault and quit yade. The length of O.bodies is similar to The one before erasing.(Does not change after erasing) you can see my question in: https://answers.launchpad.net/yade/+question/668274 I'm using Ubuntu 14.04 LTS and yadedaily version: 2018.02b-85-f861843~trusty And here is my script: # -*- coding: utf-8 -*- from yade import pack, plot young=1e8 compFricDegree = 5 finalFricDegree = 35 mn,mx=Vector3(0,0,0),Vector3(.005,.005,.005) 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) psdSizes=[.1,.6,.8,.0002,.0004,.0005,.0008,.001] psdCumm=[0,.0175,.025,.4,.5,.7,.85,1] sp=pack.SpherePack() sp.makeCloud(mn,mx,psdSizes=psdSizes,psdCumm=psdCumm,distributeMass=True,num=500) sp.toSimulation(material='spheres') triax=TriaxialStressController( maxMultiplier=1.001, finalMaxMultiplier=1.0001, thickness = 0, stressMask = 7, internalCompaction=True, ) 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" ), triax, newton, ] O.dt=PWaveTimeStep() triax.goal1=triax.goal2=triax.goal3=-1 while 1: O.run(1000,True) unb=unbalancedForce() print 'porosity', triax.porosity if unb<0.01 and abs(-1-triax.meanStress)/1<.01: break bodiesToBeDeleted=[] for b in O.bodies: if b.id in range(6): continue else: if b.state.pos[0]<.002: bodiesToBeDeleted.append(b) for b in bodiesToBeDeleted: O.bodies.erase(b.id) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1767601/+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
[Yade-dev] [Bug 1764753] Re: CohesiveTriaxialTest preprocessor segfaults
** Changed in: yade
Status: New => Fix Released
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1764753
Title:
CohesiveTriaxialTest preprocessor segfaults
Status in Yade:
Fix Released
Bug description:
Hi,
I get "core dumped" crashes using CohesiveTriaxialTest preprocessor
(FileGenerator) with:
Crashing script
simu = CohesiveTriaxialTest(numberOfGrains=4)
simu.generate('simu.yade')
O.load('simu.yade')
O.step()
(or just using the "Generate" part of the GUI)
### Affected YADE versions ###
On my computer, it affects
- yadedaily (Yade 2018.02b-74-c261ac3~xenial)
- the current trunk version (Yade 2018-04-12.git-c261ac3)
I'm attaching the whole output when running a debug trunk version.
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1764753/+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
[Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken
Fixed in https://github.com/yade/trunk/commit/12ed7b43ebfe25d5566950dce2d0e489519359c1. Thanks ** Changed in: yade Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest preprocessor broken Status in Yade: Fix Released Bug description: Hi, When using either yadedaily or the latest (as of today) trunk version, CapillaryTriaxialTest preprocessor crashes at the first iteration. The backtrace obtained from a debug version of trunk is attached. I'm at the moment playing with capillary code before commit capillary scripts, but this crash happens with or without the "water" attribute of the preprocessor, ie with or without capillary Law2 in the engines, and with both yadedaily and trunk, so I do not think it's related. The crash occurs by the way during some IGeom operations, and the structure of O.engines defined by the preprocessor looks quite outdated (no InteractionLoop()). Anyway, I would happily hear from you that the same bug exists on other computers. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1625850/+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
[Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken
Actually, I think the present bug is the same as the newly reported https://bugs.launchpad.net/yade/+bug/1764753 Out of 4 FileGenerator, we have - two conforming the "new" (though years old) InteractionLoop definition, and that run: TriaxialTest and SimpleShear - two not conforming this definition but still directly including IGeom, IPhys, and Law2 classes directly in the engines list, and that segfault: CapillaryTriaxialTest and CohesiveTriaxialTest. And in these two buggy FileGenerators, crashs seem to occur in connection with IGeom operations.. Do we now agree to (try to ?) fix these FileGenerators with the new InteractionLoop definition, if not discarding them ? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest preprocessor broken Status in Yade: Confirmed Bug description: Hi, When using either yadedaily or the latest (as of today) trunk version, CapillaryTriaxialTest preprocessor crashes at the first iteration. The backtrace obtained from a debug version of trunk is attached. I'm at the moment playing with capillary code before commit capillary scripts, but this crash happens with or without the "water" attribute of the preprocessor, ie with or without capillary Law2 in the engines, and with both yadedaily and trunk, so I do not think it's related. The crash occurs by the way during some IGeom operations, and the structure of O.engines defined by the preprocessor looks quite outdated (no InteractionLoop()). Anyway, I would happily hear from you that the same bug exists on other computers. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1625850/+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
[Yade-dev] [Bug 1764753] Re: CohesiveTriaxialTest preprocessor segfaults
See common symptoms (and common cause as well as common fix possibility
?) at https://bugs.launchpad.net/yade/+bug/1625850.
Discussing further therein
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1764753
Title:
CohesiveTriaxialTest preprocessor segfaults
Status in Yade:
New
Bug description:
Hi,
I get "core dumped" crashes using CohesiveTriaxialTest preprocessor
(FileGenerator) with:
Crashing script
simu = CohesiveTriaxialTest(numberOfGrains=4)
simu.generate('simu.yade')
O.load('simu.yade')
O.step()
(or just using the "Generate" part of the GUI)
### Affected YADE versions ###
On my computer, it affects
- yadedaily (Yade 2018.02b-74-c261ac3~xenial)
- the current trunk version (Yade 2018-04-12.git-c261ac3)
I'm attaching the whole output when running a debug trunk version.
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1764753/+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
[Yade-dev] [Bug 1764753] [NEW] CohesiveTriaxialTest preprocessor segfaults
Public bug reported:
Hi,
I get "core dumped" crashes using CohesiveTriaxialTest preprocessor
(FileGenerator) with:
Crashing script
simu = CohesiveTriaxialTest(numberOfGrains=4)
simu.generate('simu.yade')
O.load('simu.yade')
O.step()
(or just using the "Generate" part of the GUI)
### Affected YADE versions ###
On my computer, it affects
- yadedaily (Yade 2018.02b-74-c261ac3~xenial)
- the current trunk version (Yade 2018-04-12.git-c261ac3)
I'm attaching the whole output when running a debug trunk version.
** Affects: yade
Importance: Undecided
Status: New
** Attachment added: "bugCohTT.log"
https://bugs.launchpad.net/bugs/1764753/+attachment/5119429/+files/bugCohTT.log
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1764753
Title:
CohesiveTriaxialTest preprocessor segfaults
Status in Yade:
New
Bug description:
Hi,
I get "core dumped" crashes using CohesiveTriaxialTest preprocessor
(FileGenerator) with:
Crashing script
simu = CohesiveTriaxialTest(numberOfGrains=4)
simu.generate('simu.yade')
O.load('simu.yade')
O.step()
(or just using the "Generate" part of the GUI)
### Affected YADE versions ###
On my computer, it affects
- yadedaily (Yade 2018.02b-74-c261ac3~xenial)
- the current trunk version (Yade 2018-04-12.git-c261ac3)
I'm attaching the whole output when running a debug trunk version.
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1764753/+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
[Yade-dev] [Bug 1759633] Re: The Code is crashed when there are two balls with same position and radius
Hi, It's true using the "wrong code" I got an infinite (it seems) number of "ValueError: cannot convert float NaN to integer" even when running just one iteration. Is it what you call "code is crashed" ? If yes, could you please try to shorten your script ? (for this behavior to occur do we need 4 spheres ? everything coming after O.step() ?) See if this is periodic boundary-dependent, or more general ? Jérôme -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1759633 Title: The Code is crashed when there are two balls with same position and radius Status in Yade: New Bug description: I just find that if there are two balls with the same position and radius and the program is crashed without any information. To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1759633/+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
[Yade-dev] [Bug 1764424] [NEW] MeasureCapStress-caused segmentation fault (boost::python)
Public bug reported: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade- dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3) ,NewtonIntegrator() ,GlobalStiffnessTimeStepper() ,MeasureCapStress(iterPeriod=1) ] O.run() ### End of script example ### [*] https://github.com/yade/trunk/blob/master/pkg/dem/MeasureCapStress.cpp#L63. While another boost:python: appears L64, it seems L63 is enough to cause the crash. Indeed, crash also occurs when just hardcoding in L64 "volume = 1.0;" (making L63 useless but still annoying enough to cause the crash) ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1764424 Title: MeasureCapStress-caused segmentation fault (boost::python) Status in Yade: New Bug description: Hi, I'm currently facing segmentation fault when using "my" MeasureCapStress post-processing engine (this constitutes a regression..). A example script appears at the end of this message (it's better, though not necessary here, to have the capillary files from https://www.yade-dem.org/w/images/d/d2/CapillaryFiles2016.tar.gz). I get the crash with the trunk version as of today or yadedaily (for instance), and having Python 2.7.12 installed on my machine. There is some random pattern in the way crashs occur, with e.g. the following messages: - *** Error in `/usr/bin/python': free(): invalid pointer: 0x008fa220 *** followed by plenty of "Backtrace" and "Memory map" lines ending with "Aborted (core dumped)" - or just "Segmentation fault (core dumped)" that appear after a variable number (not much, though) of iterations. It seems also possible to go through a greater number of iterations by hand-clicking on GUI step button than by asking O.run()... Anyway, the crash seems to occur during (or just after) the definition of a boost::python::tuple variable, equal to Shop::aabbExtrema(), at [*]. I'm quite puzzled by all this, would someone have an idea ? Is there any particular (de-allocating ?) practice to follow when using such Python-C interfaced variables in the C++ code ? Thank you very much, Jerome ### Script example ### # two contacting particles with a capillary bridge inbetween. Segfaults because of MeasureCapStress on my machine r1,r2 = 1e-4,4e-4 z1,z2=0,0.95*(r1+r2) O.bodies.append(sphere(center=Vector3(0,0,z1),radius=r1,dynamic=0)) O.bodies.append(sphere(center=Vector3(0,0,z2),radius=r2,dynamic=0)) O.engines=[ForceResetter() ,InsertionSortCollider([Bo1_Sphere_Aabb()]) ,InteractionLoop( [Ig2_Sphere_Sphere_ScGeom()], [Ip2_FrictMat_FrictMat_CapillaryPhys()], [Law2_ScGeom_FrictPhys_CundallStrack(neverErase=1)] ) ,Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1e3)
[Yade-dev] [Bug 1746037] Re: Doc of cylinder-related models
Thank you Bruno for comments. I may come back on the naming convention
in relation with inheritance later on, in the mean time I fixed 4. at
least (not related with inheritance discussion) in
https://github.com/yade/trunk/commit/ddb86b587cb500bb5ff141bd802dbb579cca3fb1
and won't touch the rest.
** Changed in: yade
Status: New => Fix Released
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1746037
Title:
Doc of cylinder-related models
Status in Yade:
Fix Released
Bug description:
Hello,
I have few questions regarding the doc of chained cylinders classes
and such.
1. It seems to me the doc ("doc" string of YADE_CLASS_BASE_DOC_*) of
Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment [1] and
Law2_CylScGeom_FrictPhys_CundallStrack [2] may deserve some improvements.
At the moment, they look very like the doc of
Law2_ScGeom_FrictPhys_CundallStrack [3] even though
Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment does have cohesion for instance ;-)
2. I would have a similar remark (about room for improvement) for the doc of
ChCylGeom6D [4]
3. Do we agree Ig2_ChainedCylinder_ChainedCylinder_ScGeom6D actually return a
ChCylGeom6D instance [5] ?
And neither a ScGeom6D (as the name suggests), nor a ScGeom (as the doc [6]
suggests)
4. Do we agree "ScPFaceCoGeom" actually is "ScGridCoGeom" in the doc of
Ig2_Sphere_PFacet_ScGridCoGeom [7] ?
I did not make yet the modifications myself because I'm just discovering this
part of the code, but, if necessary, I could take care of most of the
corrections after minimal discussion here.
Jérôme
[1]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment
[2]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_CylScGeom_FrictPhys_CundallStrack
[3]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom_FrictPhys_CundallStrack
[4] https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.ChCylGeom6D
[5]
https://github.com/yade/trunk/blob/e4e757f2e98a620e3177b7a36a1d10f69f6a6a28/pkg/common/Cylinder.cpp#L388
[6]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ig2_ChainedCylinder_ChainedCylinder_ScGeom6D
[7]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ig2_Sphere_PFacet_ScGridCoGeom
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1746037/+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
[Yade-dev] [Bug 1746037] [NEW] Doc of cylinder-related models
Public bug reported:
Hello,
I have few questions regarding the doc of chained cylinders classes and
such.
1. It seems to me the doc ("doc" string of YADE_CLASS_BASE_DOC_*) of
Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment [1] and
Law2_CylScGeom_FrictPhys_CundallStrack [2] may deserve some improvements.
At the moment, they look very like the doc of
Law2_ScGeom_FrictPhys_CundallStrack [3] even though
Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment does have cohesion for instance ;-)
2. I would have a similar remark (about room for improvement) for the doc of
ChCylGeom6D [4]
3. Do we agree Ig2_ChainedCylinder_ChainedCylinder_ScGeom6D actually return a
ChCylGeom6D instance [5] ?
And neither a ScGeom6D (as the name suggests), nor a ScGeom (as the doc [6]
suggests)
4. Do we agree "ScPFaceCoGeom" actually is "ScGridCoGeom" in the doc of
Ig2_Sphere_PFacet_ScGridCoGeom [7] ?
I did not make yet the modifications myself because I'm just discovering this
part of the code, but, if necessary, I could take care of most of the
corrections after minimal discussion here.
Jérôme
[1]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment
[2]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_CylScGeom_FrictPhys_CundallStrack
[3]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom_FrictPhys_CundallStrack
[4] https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.ChCylGeom6D
[5]
https://github.com/yade/trunk/blob/e4e757f2e98a620e3177b7a36a1d10f69f6a6a28/pkg/common/Cylinder.cpp#L388
[6]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ig2_ChainedCylinder_ChainedCylinder_ScGeom6D
[7]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ig2_Sphere_PFacet_ScGridCoGeom
** Affects: yade
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1746037
Title:
Doc of cylinder-related models
Status in Yade:
New
Bug description:
Hello,
I have few questions regarding the doc of chained cylinders classes
and such.
1. It seems to me the doc ("doc" string of YADE_CLASS_BASE_DOC_*) of
Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment [1] and
Law2_CylScGeom_FrictPhys_CundallStrack [2] may deserve some improvements.
At the moment, they look very like the doc of
Law2_ScGeom_FrictPhys_CundallStrack [3] even though
Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment does have cohesion for instance ;-)
2. I would have a similar remark (about room for improvement) for the doc of
ChCylGeom6D [4]
3. Do we agree Ig2_ChainedCylinder_ChainedCylinder_ScGeom6D actually return a
ChCylGeom6D instance [5] ?
And neither a ScGeom6D (as the name suggests), nor a ScGeom (as the doc [6]
suggests)
4. Do we agree "ScPFaceCoGeom" actually is "ScGridCoGeom" in the doc of
Ig2_Sphere_PFacet_ScGridCoGeom [7] ?
I did not make yet the modifications myself because I'm just discovering this
part of the code, but, if necessary, I could take care of most of the
corrections after minimal discussion here.
Jérôme
[1]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ChCylGeom6D_CohFrictPhys_CohesionMoment
[2]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_CylScGeom_FrictPhys_CundallStrack
[3]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom_FrictPhys_CundallStrack
[4] https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.ChCylGeom6D
[5]
https://github.com/yade/trunk/blob/e4e757f2e98a620e3177b7a36a1d10f69f6a6a28/pkg/common/Cylinder.cpp#L388
[6]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ig2_ChainedCylinder_ChainedCylinder_ScGeom6D
[7]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Ig2_Sphere_PFacet_ScGridCoGeom
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1746037/+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
[Yade-dev] [Bug 1671045] Re: Missing reference [Duriez2016]
Sorry about that, this label has been renamed at one point. It is now fixed https://github.com/yade/trunk/commit/d3c524c4fbd0fc8406df5b5463ef2236297f198c ** Changed in: yade Status: New => Fix Released ** Changed in: yade Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1671045 Title: Missing reference [Duriez2016] Status in Yade: Fix Committed Bug description: The documentation of Ip2_JCFpmMat_JCFpmMat_JCFpmPhys contains a reference [Duriez2016]_ this label does not exist. I found that through the compile warnings. Can you please check Jerome? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1671045/+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
[Yade-dev] [Bug 1652529] Re: segmentation fault (core dumped)
It turns out yadedaily is older than I thought.. I still confirm this is
just yade-version related, the "Welcome to Yade 2016.06a-24" suggesting
that this yadedaily is the same as 2016.06a you initially considered..
I do not have a clear understanding of the update frequence of yadedaily
(and wonder if it is actually updated these days), but there is a simple
test for you to check if your yade version is compatible with the most
recent capillary files.
Just type in YADE terminal "CapillaryPhys().dict()" and check whether "nn11"
and "nn33" are listed among the attributes of this class:
- Yes => your yade version is younger than last September, you're good to go
with the recent capillary files
- No => your yade version is too old, you have to update (directly from github,
I'd now recommend).
Or go back to previous capillary files version: they are still on
https://www.yade-dem.org/wiki/Special:ListFiles as CapillaryJune2012.tar.gz (I
do not recommend it though)
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1652529
Title:
segmentation fault (core dumped)
Status in Yade:
Invalid
Bug description:
Hi I am trying to run this code, which is an example given in the
package. But every time i try to execute this file, i get segmentation
fault error. I am using Ubuntu 16.04 LTS and Yade 2016.06a
#!/usr/bin/python
# -*- coding: utf-8 -*-
"""
To run this script you need to have all 10 text files from
https://yade-dem.org/wiki/CapillaryTriaxialTest
in the same folder as you run this script in console!
This script shows how to use Law2_ScGeom_CapillaryPhys_Capillarity. The user
can switch between hertz and
linear model by setting "model_type"
"""
model_type = 1 #1=Hertz model with capillary forces,
else linear model with capillary model
#some parameters:
shear_modulus = 1e5
poisson_ratio = 0.3
young_modulus = 2*shear_modulus*(1+poisson_ratio)
friction = 0.5
angle = atan(friction)
local_damping = 0.01
viscous_normal= 0.021
viscous_shear = 0.8*viscous_normal
lowercorner = Vector3(0,0,0)
uppercorner = Vector3(0.002,0.002,0.004)
#creating a material (FrictMat):
id_SphereMat=O.materials.append(FrictMat(young=young_modulus,poisson=poisson_ratio,density=2500,frictionAngle=angle))
SphereMat=O.materials[id_SphereMat]
#generate particles:
sp=pack.SpherePack()
sp.makeCloud(lowercorner,uppercorner,.0002,rRelFuzz=.3)
O.bodies.append([sphere(c,r,material=SphereMat) for c,r in sp])
#generate boundary:
O.bodies.append(geom.facetBox(uppercorner/2,uppercorner/2,wire=True,fixed=True,material=SphereMat))
#define engines:
if model_type == 1:#hertz model with capillary forces
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_MindlinCapillaryPhys(label='ContactModel')],#for hertz
model only
[Law2_ScGeom_MindlinPhys_Mindlin()]#for hertz model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for hertz model
only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
ContactModel.betan=viscous_normal
ContactModel.betas=viscous_shear
ContactModel.useDamping=True
else:
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_CapillaryPhys()],#for
linear model only
[Law2_ScGeom_FrictPhys_CundallStrack()],#for
linear model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for linear
model only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
#set time step and run simulation:
O.dt=0.5*PWaveTimeStep()
from yade import qt
qt.View()
print('Press PLAY button')
#O.run(1,True)
looking forward to hear soon..!!
Cheers
Amiya
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1652529/+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
[Yade-dev] [Bug 1652529] Re: segmentation fault (core dumped)
Indeed, with the latest capillary files, you have to use some yade
version younger than end of last September (which is not your case now).
You could either directly pull the last trunk (see "working with source
code" in [*]), or use packaged "yadedaily" which should most probably
work as well.
If you're not in a rush, another stable release (i.e. the child of
2016.06a) should be published soon (do not know exactly when). This one
would also work
[*] https://yade-dem.org/doc/installation.html
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1652529
Title:
segmentation fault (core dumped)
Status in Yade:
Invalid
Bug description:
Hi I am trying to run this code, which is an example given in the
package. But every time i try to execute this file, i get segmentation
fault error. I am using Ubuntu 16.04 LTS and Yade 2016.06a
#!/usr/bin/python
# -*- coding: utf-8 -*-
"""
To run this script you need to have all 10 text files from
https://yade-dem.org/wiki/CapillaryTriaxialTest
in the same folder as you run this script in console!
This script shows how to use Law2_ScGeom_CapillaryPhys_Capillarity. The user
can switch between hertz and
linear model by setting "model_type"
"""
model_type = 1 #1=Hertz model with capillary forces,
else linear model with capillary model
#some parameters:
shear_modulus = 1e5
poisson_ratio = 0.3
young_modulus = 2*shear_modulus*(1+poisson_ratio)
friction = 0.5
angle = atan(friction)
local_damping = 0.01
viscous_normal= 0.021
viscous_shear = 0.8*viscous_normal
lowercorner = Vector3(0,0,0)
uppercorner = Vector3(0.002,0.002,0.004)
#creating a material (FrictMat):
id_SphereMat=O.materials.append(FrictMat(young=young_modulus,poisson=poisson_ratio,density=2500,frictionAngle=angle))
SphereMat=O.materials[id_SphereMat]
#generate particles:
sp=pack.SpherePack()
sp.makeCloud(lowercorner,uppercorner,.0002,rRelFuzz=.3)
O.bodies.append([sphere(c,r,material=SphereMat) for c,r in sp])
#generate boundary:
O.bodies.append(geom.facetBox(uppercorner/2,uppercorner/2,wire=True,fixed=True,material=SphereMat))
#define engines:
if model_type == 1:#hertz model with capillary forces
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_MindlinCapillaryPhys(label='ContactModel')],#for hertz
model only
[Law2_ScGeom_MindlinPhys_Mindlin()]#for hertz model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for hertz model
only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
ContactModel.betan=viscous_normal
ContactModel.betas=viscous_shear
ContactModel.useDamping=True
else:
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_CapillaryPhys()],#for
linear model only
[Law2_ScGeom_FrictPhys_CundallStrack()],#for
linear model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for linear
model only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
#set time step and run simulation:
O.dt=0.5*PWaveTimeStep()
from yade import qt
qt.View()
print('Press PLAY button')
#O.run(1,True)
looking forward to hear soon..!!
Cheers
Amiya
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1652529/+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
[Yade-dev] [Bug 1652529] Re: segmentation fault (core dumped)
Note your issue may also be related with the capillary files you're using. The
capillary source code has been updated together with capillary files end of
September, 2016.
You have to use compatible yade version and capillary files.
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1652529
Title:
segmentation fault (core dumped)
Status in Yade:
Invalid
Bug description:
Hi I am trying to run this code, which is an example given in the
package. But every time i try to execute this file, i get segmentation
fault error. I am using Ubuntu 16.04 LTS and Yade 2016.06a
#!/usr/bin/python
# -*- coding: utf-8 -*-
"""
To run this script you need to have all 10 text files from
https://yade-dem.org/wiki/CapillaryTriaxialTest
in the same folder as you run this script in console!
This script shows how to use Law2_ScGeom_CapillaryPhys_Capillarity. The user
can switch between hertz and
linear model by setting "model_type"
"""
model_type = 1 #1=Hertz model with capillary forces,
else linear model with capillary model
#some parameters:
shear_modulus = 1e5
poisson_ratio = 0.3
young_modulus = 2*shear_modulus*(1+poisson_ratio)
friction = 0.5
angle = atan(friction)
local_damping = 0.01
viscous_normal= 0.021
viscous_shear = 0.8*viscous_normal
lowercorner = Vector3(0,0,0)
uppercorner = Vector3(0.002,0.002,0.004)
#creating a material (FrictMat):
id_SphereMat=O.materials.append(FrictMat(young=young_modulus,poisson=poisson_ratio,density=2500,frictionAngle=angle))
SphereMat=O.materials[id_SphereMat]
#generate particles:
sp=pack.SpherePack()
sp.makeCloud(lowercorner,uppercorner,.0002,rRelFuzz=.3)
O.bodies.append([sphere(c,r,material=SphereMat) for c,r in sp])
#generate boundary:
O.bodies.append(geom.facetBox(uppercorner/2,uppercorner/2,wire=True,fixed=True,material=SphereMat))
#define engines:
if model_type == 1:#hertz model with capillary forces
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_MindlinCapillaryPhys(label='ContactModel')],#for hertz
model only
[Law2_ScGeom_MindlinPhys_Mindlin()]#for hertz model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for hertz model
only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
ContactModel.betan=viscous_normal
ContactModel.betas=viscous_shear
ContactModel.useDamping=True
else:
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_CapillaryPhys()],#for
linear model only
[Law2_ScGeom_FrictPhys_CundallStrack()],#for
linear model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for linear
model only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
#set time step and run simulation:
O.dt=0.5*PWaveTimeStep()
from yade import qt
qt.View()
print('Press PLAY button')
#O.run(1,True)
looking forward to hear soon..!!
Cheers
Amiya
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1652529/+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
[Yade-dev] [Bug 1652529] Re: segmentation fault (core dumped)
Hello,
I can not reproduce the bug: I've tried this example [*] (since it is a
file from "examples" folder, you may just refer directly to it, so that
we're sure it has not been altered) with two recent versions (2016-10-31
.git-1b22b1a and the last one 2016-12-20.git-54c46f3) and did not get
any crash.
I'm marking thus the bug for now as "invalid", before any new
information. You may give us copy of the whole YADE output when you
launch this script, for instance.
Jerome
[*]
https://github.com/yade/trunk/blob/master/examples/capillaryLaplaceYoung
/CapillaryPhys-example.py
** Changed in: yade
Status: New => Invalid
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1652529
Title:
segmentation fault (core dumped)
Status in Yade:
Invalid
Bug description:
Hi I am trying to run this code, which is an example given in the
package. But every time i try to execute this file, i get segmentation
fault error. I am using Ubuntu 16.04 LTS and Yade 2016.06a
#!/usr/bin/python
# -*- coding: utf-8 -*-
"""
To run this script you need to have all 10 text files from
https://yade-dem.org/wiki/CapillaryTriaxialTest
in the same folder as you run this script in console!
This script shows how to use Law2_ScGeom_CapillaryPhys_Capillarity. The user
can switch between hertz and
linear model by setting "model_type"
"""
model_type = 1 #1=Hertz model with capillary forces,
else linear model with capillary model
#some parameters:
shear_modulus = 1e5
poisson_ratio = 0.3
young_modulus = 2*shear_modulus*(1+poisson_ratio)
friction = 0.5
angle = atan(friction)
local_damping = 0.01
viscous_normal= 0.021
viscous_shear = 0.8*viscous_normal
lowercorner = Vector3(0,0,0)
uppercorner = Vector3(0.002,0.002,0.004)
#creating a material (FrictMat):
id_SphereMat=O.materials.append(FrictMat(young=young_modulus,poisson=poisson_ratio,density=2500,frictionAngle=angle))
SphereMat=O.materials[id_SphereMat]
#generate particles:
sp=pack.SpherePack()
sp.makeCloud(lowercorner,uppercorner,.0002,rRelFuzz=.3)
O.bodies.append([sphere(c,r,material=SphereMat) for c,r in sp])
#generate boundary:
O.bodies.append(geom.facetBox(uppercorner/2,uppercorner/2,wire=True,fixed=True,material=SphereMat))
#define engines:
if model_type == 1:#hertz model with capillary forces
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_MindlinCapillaryPhys(label='ContactModel')],#for hertz
model only
[Law2_ScGeom_MindlinPhys_Mindlin()]#for hertz model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for hertz model
only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
ContactModel.betan=viscous_normal
ContactModel.betas=viscous_shear
ContactModel.useDamping=True
else:
O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb()]),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_CapillaryPhys()],#for
linear model only
[Law2_ScGeom_FrictPhys_CundallStrack()],#for
linear model only
),
Law2_ScGeom_CapillaryPhys_Capillarity(capillaryPressure=1),#for linear
model only
NewtonIntegrator(damping=local_damping,gravity=(0,0,-9.81)),
]
#set time step and run simulation:
O.dt=0.5*PWaveTimeStep()
from yade import qt
qt.View()
print('Press PLAY button')
#O.run(1,True)
looking forward to hear soon..!!
Cheers
Amiya
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1652529/+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
[Yade-dev] [Bug 1628273] Re: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity
Hopefully solved by following commit https://github.com/yade/trunk/commit/dd0b300d3d75ac5b3f3a701cec135d966343c922 ** Changed in: yade Status: New => Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1628273 Title: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity Status in Yade: Fix Released Bug description: Hi, Let say one performs simulation with Law2_ScGeom_CapillaryPhys_Capillarity and Law2_ScGeom_FrictPhys_CundallStrack.neverErase = 1 (in order to keep menisci between separated particles) In such case, interactions between sphere and non spherical particles (e.g. boundaries) are not deleted by Law2_ScGeom_FrictPhys_CundallStrack when geometrical contact is lost, and are neither handled (deleted because of no meniscus, in particular) by Law2_ScGeom_CapillaryPhys_Capillarity because Law2_ScGeom_CapillaryPhys_Capillarity simply disregards such interaction [*]. And the user ends up with much more interactions than necessary.. I'm filling a Bug report for the record and possible discussion about desired behaviour (sorry I could not provide a MWE !) Jerome [*] https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L98 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1628273/+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
[Yade-dev] [Bug 1508231] Re: O.reset resets O.tags['params']
Somewhat similar to another proposed bug [*]. We decided the other situation was just a feature, applying same treatment here [*] https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg12040.html ** Changed in: yade Status: New => Invalid -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1508231 Title: O.reset resets O.tags['params'] Status in Yade: Invalid Bug description: Hello, See the attached files to launch in batch mode yade-batch test.table test.py As suggested by the title, you will see that using O.reset() prevents accessing subsequently O.tags['params'] Reporting so that we may decide if this a bug or not. At least, it let crash unexpectedly one of my simulations. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1508231/+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
[Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken
(I'm answering here to http://www.mail-archive.com/yade- d...@lists.launchpad.net/msg12167.html that does not appear on the bug webpage ?) >From my point of view, I do not propose at all to hide a bug. My understanding of the situation is that CapillaryTriaxialTest preprocessor had not been updated when necessary to reflect YADE changes, contrary to e.g. TriaxialTest preprocessor. As I said, CapillaryTriaxialTest does not include any InteractionLoop, for instance (TriaxialTest obviously does). If I'm right, solving the "bug" would just require to update the engines definition of CapillaryTriaxialTest, to reflect the current YADE architecture. Since we already have working TriaxialTest preprocessor and examples/capillaryLaplaceYoung folder, I do not see the point fixing the CapillaryTriaxialTest preprocessor in this sense, hence my previous proposition. -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest preprocessor broken Status in Yade: New Bug description: Hi, When using either yadedaily or the latest (as of today) trunk version, CapillaryTriaxialTest preprocessor crashes at the first iteration. The backtrace obtained from a debug version of trunk is attached. I'm at the moment playing with capillary code before commit capillary scripts, but this crash happens with or without the "water" attribute of the preprocessor, ie with or without capillary Law2 in the engines, and with both yadedaily and trunk, so I do not think it's related. The crash occurs by the way during some IGeom operations, and the structure of O.engines defined by the preprocessor looks quite outdated (no InteractionLoop()). Anyway, I would happily hear from you that the same bug exists on other computers. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1625850/+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
[Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken
Regarding this bug, I think the CapillaryTriaxialTest preprocessor does not add much to Yade now (even in a working state), and propose to remove CapillaryTriaxialTest.*pp from the code. Either using git rm, or adding #ifdef DEPREC_CODE (I vote for the former) Agree ? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest preprocessor broken Status in Yade: New Bug description: Hi, When using either yadedaily or the latest (as of today) trunk version, CapillaryTriaxialTest preprocessor crashes at the first iteration. The backtrace obtained from a debug version of trunk is attached. I'm at the moment playing with capillary code before commit capillary scripts, but this crash happens with or without the "water" attribute of the preprocessor, ie with or without capillary Law2 in the engines, and with both yadedaily and trunk, so I do not think it's related. The crash occurs by the way during some IGeom operations, and the structure of O.engines defined by the preprocessor looks quite outdated (no InteractionLoop()). Anyway, I would happily hear from you that the same bug exists on other computers. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1625850/+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
[Yade-dev] [Bug 1628273] Re: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity
Hi, Just to give some figures about this bug: Random examples of triaxial simulations (with 2 spherical particles and 6 boxes) show here ~ 45% of sphere-wall interactions that are useless at the end of the simulation. Ie ~ 3% of the (real) interactions total number. I think checking for penetrationDepth < 0 around l.95 of the code [1], before deciding to "continue", would make sense and solve this bug. OK ? Do we take the opportunity to replace the shape test [2] with something else ? (what ? if yes) Jerome [1] https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L95 [2] https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L98 -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1628273 Title: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity Status in Yade: New Bug description: Hi, Let say one performs simulation with Law2_ScGeom_CapillaryPhys_Capillarity and Law2_ScGeom_FrictPhys_CundallStrack.neverErase = 1 (in order to keep menisci between separated particles) In such case, interactions between sphere and non spherical particles (e.g. boundaries) are not deleted by Law2_ScGeom_FrictPhys_CundallStrack when geometrical contact is lost, and are neither handled (deleted because of no meniscus, in particular) by Law2_ScGeom_CapillaryPhys_Capillarity because Law2_ScGeom_CapillaryPhys_Capillarity simply disregards such interaction [*]. And the user ends up with much more interactions than necessary.. I'm filling a Bug report for the record and possible discussion about desired behaviour (sorry I could not provide a MWE !) Jerome [*] https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L98 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1628273/+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
[Yade-dev] [Bug 1628273] Re: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity
We realized it thanks to a colleague who was working on interaction data, as exported in a text file. However we did not quantify it precisely yet (and I'm now away from office for a couple of weeks) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1628273 Title: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity Status in Yade: New Bug description: Hi, Let say one performs simulation with Law2_ScGeom_CapillaryPhys_Capillarity and Law2_ScGeom_FrictPhys_CundallStrack.neverErase = 1 (in order to keep menisci between separated particles) In such case, interactions between sphere and non spherical particles (e.g. boundaries) are not deleted by Law2_ScGeom_FrictPhys_CundallStrack when geometrical contact is lost, and are neither handled (deleted because of no meniscus, in particular) by Law2_ScGeom_CapillaryPhys_Capillarity because Law2_ScGeom_CapillaryPhys_Capillarity simply disregards such interaction [*]. And the user ends up with much more interactions than necessary.. I'm filling a Bug report for the record and possible discussion about desired behaviour (sorry I could not provide a MWE !) Jerome [*] https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L98 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1628273/+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
[Yade-dev] [Bug 1628273] [NEW] Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity
Public bug reported: Hi, Let say one performs simulation with Law2_ScGeom_CapillaryPhys_Capillarity and Law2_ScGeom_FrictPhys_CundallStrack.neverErase = 1 (in order to keep menisci between separated particles) In such case, interactions between sphere and non spherical particles (e.g. boundaries) are not deleted by Law2_ScGeom_FrictPhys_CundallStrack when geometrical contact is lost, and are neither handled (deleted because of no meniscus, in particular) by Law2_ScGeom_CapillaryPhys_Capillarity because Law2_ScGeom_CapillaryPhys_Capillarity simply disregards such interaction [*]. And the user ends up with much more interactions than necessary.. I'm filling a Bug report for the record and possible discussion about desired behaviour (sorry I could not provide a MWE !) Jerome [*] https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L98 ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1628273 Title: Sphere - nonSphere interactions never deleted by Law2_ScGeom_CapillaryPhys_Capillarity Status in Yade: New Bug description: Hi, Let say one performs simulation with Law2_ScGeom_CapillaryPhys_Capillarity and Law2_ScGeom_FrictPhys_CundallStrack.neverErase = 1 (in order to keep menisci between separated particles) In such case, interactions between sphere and non spherical particles (e.g. boundaries) are not deleted by Law2_ScGeom_FrictPhys_CundallStrack when geometrical contact is lost, and are neither handled (deleted because of no meniscus, in particular) by Law2_ScGeom_CapillaryPhys_Capillarity because Law2_ScGeom_CapillaryPhys_Capillarity simply disregards such interaction [*]. And the user ends up with much more interactions than necessary.. I'm filling a Bug report for the record and possible discussion about desired behaviour (sorry I could not provide a MWE !) Jerome [*] https://github.com/yade/trunk/blob/master/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp#L98 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1628273/+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
[Yade-dev] [Bug 1625850] Re: CapillaryTriaxialTest preprocessor broken
They are 2 years old: https://github.com/yade/trunk/commits/master/pkg/dem/CapillaryTriaxialTest.hpp https://github.com/yade/trunk/commits/master/pkg/dem/CapillaryTriaxialTest.cpp As for myself, in particular, I never touched them (except for the stress sign convention thing). I think this preprocessor is simply deprecated, with the engine list declaration being now not consistent with YADE architecture. There is no InteractionLoop definition for instance (as opposed to TriaxialTest other preprocessor) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest preprocessor broken Status in Yade: New Bug description: Hi, When using either yadedaily or the latest (as of today) trunk version, CapillaryTriaxialTest preprocessor crashes at the first iteration. The backtrace obtained from a debug version of trunk is attached. I'm at the moment playing with capillary code before commit capillary scripts, but this crash happens with or without the "water" attribute of the preprocessor, ie with or without capillary Law2 in the engines, and with both yadedaily and trunk, so I do not think it's related. The crash occurs by the way during some IGeom operations, and the structure of O.engines defined by the preprocessor looks quite outdated (no InteractionLoop()). Anyway, I would happily hear from you that the same bug exists on other computers. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1625850/+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
[Yade-dev] [Bug 1625850] [NEW] CapillaryTriaxialTest preprocessor broken
Public bug reported: Hi, When using either yadedaily or the latest (as of today) trunk version, CapillaryTriaxialTest preprocessor crashes at the first iteration. The backtrace obtained from a debug version of trunk is attached. I'm at the moment playing with capillary code before commit capillary scripts, but this crash happens with or without the "water" attribute of the preprocessor, ie with or without capillary Law2 in the engines, and with both yadedaily and trunk, so I do not think it's related. The crash occurs by the way during some IGeom operations, and the structure of O.engines defined by the preprocessor looks quite outdated (no InteractionLoop()). Anyway, I would happily hear from you that the same bug exists on other computers. Jerome ** Affects: yade Importance: Undecided Status: New ** Attachment added: "backtrace.txt" https://bugs.launchpad.net/bugs/1625850/+attachment/4744660/+files/backtrace.txt -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1625850 Title: CapillaryTriaxialTest preprocessor broken Status in Yade: New Bug description: Hi, When using either yadedaily or the latest (as of today) trunk version, CapillaryTriaxialTest preprocessor crashes at the first iteration. The backtrace obtained from a debug version of trunk is attached. I'm at the moment playing with capillary code before commit capillary scripts, but this crash happens with or without the "water" attribute of the preprocessor, ie with or without capillary Law2 in the engines, and with both yadedaily and trunk, so I do not think it's related. The crash occurs by the way during some IGeom operations, and the structure of O.engines defined by the preprocessor looks quite outdated (no InteractionLoop()). Anyway, I would happily hear from you that the same bug exists on other computers. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1625850/+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
[Yade-dev] [Bug 1604125] [NEW] gtsSurfaceBestFitOBB() broken
Public bug reported:
Hello,
It seems the pack.gtsSurfaceBestFitOBB() function is broken in recent
YADE versions. Just type the following (using a gts file present in the
sources) in your YADE terminal:
**
import gts
surface=gts.read(open('parallellepiped.gts')) # the one from
examples/jointedCohesiveFrictionalPM
pred=pack.inGtsSurface(surface)
print 'Dim from pred.dim = ',pred.dim()
center,dim,orientation=gtsSurfaceBestFitOBB(surface)
print 'Dim from gtsSurfaceBestFitOBB =',dim
***
I get the correct output with a not up to date YADE version as follows:
***
Dim from pred.dim = Vector3(0.999404,2.02092895,1)
Dim from gtsSurfaceBestFitOBB = Vector3(0.499702,1.01046447,0.5) #
two are "equal" with a normal factor 2
***
Whereas an up to date YADE version returns:
***
Dim from pred.dim = Vector3(0.999404,2.02092895,1)
Dim from gtsSurfaceBestFitOBB =
Vector3(6.91989746778284e-310,3.47644378095352e-310,5e-324)
***
These two versions differ for instance in the related function bestFitOBB() in
py/pack/_packObb.cpp, in relation with this commit: (the difference is exactly
the one introduced by this commit)
https://github.com/yade/trunk/commit/4f66360db75afb82029bbe37ae4a4dac36899a33
The bug affects for instance the use of randomDensePack() function with GTS
predicates:
https://answers.launchpad.net/yade/+question/297125
Any ideas ? (Anton, we need you once again ?)
Jerome
** Affects: yade
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1604125
Title:
gtsSurfaceBestFitOBB() broken
Status in Yade:
New
Bug description:
Hello,
It seems the pack.gtsSurfaceBestFitOBB() function is broken in recent
YADE versions. Just type the following (using a gts file present in
the sources) in your YADE terminal:
**
import gts
surface=gts.read(open('parallellepiped.gts')) # the one from
examples/jointedCohesiveFrictionalPM
pred=pack.inGtsSurface(surface)
print 'Dim from pred.dim = ',pred.dim()
center,dim,orientation=gtsSurfaceBestFitOBB(surface)
print 'Dim from gtsSurfaceBestFitOBB =',dim
***
I get the correct output with a not up to date YADE version as follows:
***
Dim from pred.dim = Vector3(0.999404,2.02092895,1)
Dim from gtsSurfaceBestFitOBB = Vector3(0.499702,1.01046447,0.5)
# two are "equal" with a normal factor 2
***
Whereas an up to date YADE version returns:
***
Dim from pred.dim = Vector3(0.999404,2.02092895,1)
Dim from gtsSurfaceBestFitOBB =
Vector3(6.91989746778284e-310,3.47644378095352e-310,5e-324)
***
These two versions differ for instance in the related function bestFitOBB()
in py/pack/_packObb.cpp, in relation with this commit: (the difference is
exactly the one introduced by this commit)
https://github.com/yade/trunk/commit/4f66360db75afb82029bbe37ae4a4dac36899a33
The bug affects for instance the use of randomDensePack() function with GTS
predicates:
https://answers.launchpad.net/yade/+question/297125
Any ideas ? (Anton, we need you once again ?)
Jerome
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1604125/+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
[Yade-dev] [Bug 1596021] Re: O.tags['params'] for 2 batchs and 1 save
Thanks everyone. ** Changed in: yade Status: New => Invalid -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1596021 Title: O.tags['params'] for 2 batchs and 1 save Status in Yade: Invalid Bug description: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1596021/+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
[Yade-dev] [Bug 1596021] Re: O.tags['params'] for 2 batchs and 1 save
Indeed, that's another point of view.. Mine would be that O.tags['params'] is deeply related with the batch parameters rather than anything else. I'll wait a couple of days and then mark the bug as invalid if I'm the only one thinking that way. (In fact, the solution you're proposing would not work for my case because I decide to load, or do something else, depending on the batch parameters) Speaking by the way about O.tags in general, I never use it for something else than 'params' and am curious what use can be made of it (which starts to be off topic here) Thanks ! -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1596021 Title: O.tags['params'] for 2 batchs and 1 save Status in Yade: New Bug description: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1596021/+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
[Yade-dev] [Bug 1596021] Re: O.tags['params'] for 2 batchs and 1 save
** Attachment added: "first.py" https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689846/+files/first.py -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1596021 Title: O.tags['params'] for 2 batchs and 1 save Status in Yade: New Bug description: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1596021/+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
[Yade-dev] [Bug 1596021] [NEW] O.tags['params'] for 2 batchs and 1 save
Public bug reported: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1596021 Title: O.tags['params'] for 2 batchs and 1 save Status in Yade: New Bug description: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1596021/+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
[Yade-dev] [Bug 1596021] Re: O.tags['params'] for 2 batchs and 1 save
** Attachment added: "second.py" https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689854/+files/second.py -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1596021 Title: O.tags['params'] for 2 batchs and 1 save Status in Yade: New Bug description: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1596021/+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
[Yade-dev] [Bug 1596021] Re: O.tags['params'] for 2 batchs and 1 save
** Attachment added: "first.table" https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689855/+files/first.table -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1596021 Title: O.tags['params'] for 2 batchs and 1 save Status in Yade: New Bug description: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1596021/+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
[Yade-dev] [Bug 1596021] Re: O.tags['params'] for 2 batchs and 1 save
** Attachment added: "second.table" https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689856/+files/second.table -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1596021 Title: O.tags['params'] for 2 batchs and 1 save Status in Yade: New Bug description: Hello, I've faced some issue for batch simulation. I have a batch simulation that loads a .yade save from a previous simulation that was also launched in batch mode. The two batch-mode simulations consider different parameters in their .table. And in the second simulation, O.tags['params'] refers to the parameters of the first batch-mode simulation, while I would like it refers to the parameters of the current simulation.. I'm attaching example scripts "first.py" and "second.py", together with their "first.table" and "second.table" to illustrate. "first.py" will generate a .yade that will be used by "second.py". During the batch execution of "second.py", O.tags['params'] refers to first.table instead of second.table. It turns out the O.load erases the right O.tags['params'] Do we agree it is a bug or, at least, an indesirable feature ? Would it be possible to not save O.tags['params'] in .yade files ? To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1596021/+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
[Yade-dev] [Bug 1508231] [NEW] O.reset resets O.tags['params']
Public bug reported: Hello, See the attached files to launch in batch mode yade-batch test.table test.py As suggested by the title, you will see that using O.reset() prevents accessing subsequently O.tags['params'] Reporting so that we may decide if this a bug or not. At least, it let crash unexpectedly one of my simulations. Jerome ** Affects: yade Importance: Undecided Status: New ** Attachment added: "test.table" https://bugs.launchpad.net/bugs/1508231/+attachment/4501428/+files/test.table -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1508231 Title: O.reset resets O.tags['params'] Status in Yade: New Bug description: Hello, See the attached files to launch in batch mode yade-batch test.table test.py As suggested by the title, you will see that using O.reset() prevents accessing subsequently O.tags['params'] Reporting so that we may decide if this a bug or not. At least, it let crash unexpectedly one of my simulations. Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1508231/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
To be sure I got you (and you got me): In the files, this distance does have a well defined set of values: with e.g. (I'm taking random figures) 600 lines at d = cst = 0, then 500 lines at d = cst = 1e-4, then 400 lines at d = cst = 5e-3. Up to now, I would not be able to obtain such precise set of values directly from solving 600 + 500 + 400 times the ODE. That's why I think there is a second step, after the ODE solving, to construct the capillary files. During which a choice for the d values has to be made. Don't you think so ? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yade: Fix Released Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
Hi, I'm finally working on open source scripts to regenerate capillary files from scratch. Hopefully, there will be a commit in a couple of months. In Luc Scholtes' capillary files, the d* values were not linearly spaced, as the attached figure shows it (it shows the increment between two successive d* values, and it is not constant) I see the point not taking an constant increment, but, at the - far ... - time these files were generated, was there a precise reason to take such non linear d* distribution, rather than another (non linear) ? Thanks, Jerome PS : the attached figure applies to d* values as in the capillary files before June 2012, and since April 2015. Between these dates, the d* structure was a bit different, with e.g. roughly 27 d* values instead of 50-55 ** Attachment added: d* increment values https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4430636/+files/incDstarSch.eps -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yade: Fix Released Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
PPS: the same question holds more or less for the uc* values -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yade: Fix Released Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
** Attachment added: Current uc* values (MATLAB .fig version) https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4430666/+files/ucValuesOldCorr.fig -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yade: Fix Released Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
The current uc* values distribution, for the record ** Attachment added: Current uc* values https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4430665/+files/ucValuesOldCorr.eps -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yade: Fix Released Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
Ok, it is in fact quite clear for what concerns uc* (sorry for the possible spam, the record is sometimes also for me) ** Attachment added: Current uc* values with analytical fit https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4430714/+files/ucValuesOldCorr.eps -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yade: Fix Released Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
Ok. Last question/remark before I upload the corrected files : in M(r=10), there is a bunch of missing uc* values in some cases. For dist* = 0 and 1e-4, considered uc* values jump from 1350 to 11000. This being said, trends in all values changes (according to uc*) do not show anything chocking, in this file. About your p.s. question of #7, the junk values seem to correspond to a set of few given uc* values. As such, as soon as you consider an example with a given capillary pressure that do not fit those uc* values, nothing appears. Note also that I did not spot any problem about force values. (If I understood your question) -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
Ok, so my opinion is that there is no junk force values in the files. Then, force(uc*) curves have nothing to reveal. However, there are junk volume / delta2 values (for some dist*), that get obvious on volume(uc*), or delta2(uc*), curves. See Figure ... bug attachments In the end, I think personally that the lines that include junk volume / delta2 values (but not any junk force values) do not obey Laplace's equation. For some reason... -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
Hi Vaclav, No, and I do not have this code myself. What I have is a MATLAB code I used to modify the very first version of the capillary files (I'm attaching). Luc Scholtes provided me these very first version of the files. I guess he is the only one, if any, who may have the code to generate from scratch these capillary files. (However, I was thinking it could be useful to include these text files in trunk to ease control, any thoughts ?) ** Attachment added: MATLAB file to correct existing capillary files https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4369525/+files/corrCapFiles.m -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
I do not know if I could take care of re-generating new files, but I am personly anyway curious about your script, if you agree to provide it (would also help to assess the required work amount). Fresh new files being generated or not, we agree to put now capillary files inside sources (in an extra subfolder ?) instead on wiki, that's it ? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
** Attachment added: MATLAB file to plot capillary files (see first lines as doc) https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4367949/+files/plotCapFiles.m -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] [NEW] Buggy data in capillary files
Public bug reported: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html ** Affects: yade Importance: Undecided Assignee: Jérôme Duriez (jduriez) Status: New ** Attachment added: prob.txt https://bugs.launchpad.net/bugs/1440887/+attachment/4367946/+files/prob.txt -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
** Attachment added: Figure to illustrate vol* values problems (current capillary files) https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4367947/+files/ratio2probV.eps -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1440887] Re: Buggy data in capillary files
** Attachment added: Figure to illustrate delta2 value problems (current capillary files) https://bugs.launchpad.net/yade/+bug/1440887/+attachment/4367948/+files/ratio1_1probDelta.eps -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1440887 Title: Buggy data in capillary files Status in Yet Another Dynamic Engine: New Bug description: Hi, * CURRENT SITUATION ** Current capillary files include some buggy data for dimensionless menisci volume (vol*), and filling angle delta2. Several examples are detailled in prob.txt attachment. Basically, on some lines, vol* and delta2 are discontinuous compared to adjacent lines. The discontinuous values are sometimes obviously wrong, with e.g. one vol* = 400 line 9704 of M(r=2). You may imagine the consequences on the construction of a soil-water characteristic curve... *** ** HISTORY (explaining the current situation ?) ** Historically, these files come from a very first version of capillary files, that have been corrected twice. A first (major) correction modified the volume values that were affected by a mistake during files construction (*). There has been a second (minor) correction regarding the first lines of some files (**). Probably the discontinuous volume values existing now have been introduced during the major correction (*). ** ** CORRECTION PROPOSAL After discussion with Luc Scholtes, some work has been done to correct the buggy volume / delta2 values that exist now. It has been decided to start from the very first version of the files. In this very first version no discontinuous volume values existed. But, discontinuous values of delta2, sometimes reaching - 6000 degrees have been now spotted in these very first files. To correct this, the lines including such discontinuous delta2 values have been simply erased. To do so, continuity has been checked with adjacent lines, spotting then errors like delta2 = - 6000 deg between delta2 = 55 and 54 degrees, and also delta2 = 3 degrees between 22 and 22. Doing so, roughly less than 1% of lines have been erased. Discontinuous lines being erased, volume values have been corrected towards the same direction than during correction (*). ** ** FINAL SITUATION AFTER POSSIBLE APPROVAL OF PROPOSED CORRECTION*** This work has been completed. It is not uploaded yet, time being given for people to check the current situation, and possible discussion about the correction proposal. In the brand new files (only in my PC as for now), there should be no discontinuous values of vol* and delta2 anymore, and volume meniscii should be correct. *** (*) https://answers.launchpad.net/yade/+question/201608 (**) http://www.mail-archive.com/yade-dev%40lists.launchpad.net/msg10638.html To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1440887/+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
[Yade-dev] [Bug 1394942] Re: Bug in Generate-CapillaryTriaxialTest
Hi, From my point of view this is not a bug. It is a (useful, I would say) feature introduced recently to let understand that the defined simulation will run outside the validity range of capillary files. See http://www.mail-archive.com/yade-dev@lists.launchpad.net/msg10889.html and next messages, and also thread of http://www.mail-archive.com/yade- d...@lists.launchpad.net/msg10923.html Did you face this situation with default parameters of this preprocessor ? If yes, that would be the only useful change to perform (modify capillary pressure or radii so that adimensionned capillary pressure goes back in the validity range) Jerome -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1394942 Title: Bug in Generate-CapillaryTriaxialTest Status in Yet Another Dynamic Engine: New Bug description: Hi, I just stumbled upon this error after I clicked in yadedaily in qtController - generate - CapillaryTriaxialTest - and then start simulation. Seems to be related to capillary features maybe. Normal generated TriaxialTest Working. ERROR /tmp/buildd/yadedaily-1.12.0-48-d81ac93~trusty/pkg/dem/Law2_ScGeom_CapillaryPhys_Capillarity.cpp:158 action: No meniscus found at a contact. capillaryPressure may be too large wrt. the loaded data files. machine: VirtualBox with 14.04.01 Lubuntu 64bit To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1394942/+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
[Yade-dev] [Bug 1381282] Re: Sign convention in TriaxialStressController not consistent ?
Hopefully fixed in https://github.com/yade/trunk/commit/d81ac93b9383a2ab01a75809d72826c62ee91b7c and previous commit ** Changed in: yade Status: New = Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1381282 Title: Sign convention in TriaxialStressController not consistent ? Status in Yet Another Dynamic Engine: Fix Released Bug description: Hi, When used as stress or strain rates, sign convention of goal1/2/3 attributes of TriaxialStressController engine seem to me as not consistent. Positive values for stress goals correspond indeed to compression, whereas positive values for goal strain rates involve extension. Which is itself not consistent with TriaxialStressController.strain variable (in the end, to obtain positive TriaxialStressController.strain, you need to set negative strain rates goal variables). Not difficult to fix, but maybe require a common decision. (I vote myself for geomechanics convention) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1381282/+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
[Yade-dev] [Bug 1381282] Re: Sign convention in TriaxialStressController not consistent ?
Ok, thank you. For the DEM-PFV check I thought the minus sign was the big difference. Now I'm realizing it is normal : I did not see before that the test was on Qin + Qout, instead of Qin - Qout. For the 1e-4 difference, I get for the same test the INFO message More than 60\% of cpu time in FlowEngine ( 95.0429507 %). I guess I compiled with some libraries disabled in cmake options. Could this be related with this slight discrepancy about flowrates ? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1381282 Title: Sign convention in TriaxialStressController not consistent ? Status in Yet Another Dynamic Engine: New Bug description: Hi, When used as stress or strain rates, sign convention of goal1/2/3 attributes of TriaxialStressController engine seem to me as not consistent. Positive values for stress goals correspond indeed to compression, whereas positive values for goal strain rates involve extension. Which is itself not consistent with TriaxialStressController.strain variable (in the end, to obtain positive TriaxialStressController.strain, you need to set negative strain rates goal variables). Not difficult to fix, but maybe require a common decision. (I vote myself for geomechanics convention) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1381282/+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
[Yade-dev] [Bug 1381282] Re: Sign convention in TriaxialStressController not consistent ?
I copy paste below some part of the build/CMakeCache.txt (also attached as a whole). I guess that's what you wanted. And indeed the same discrepancy in Q (with the same INFO message) appears for another version without any change in sign convention //No help, variable specified on the command line. ENABLEPFVFLOW:UNINITIALIZED=ON //Enable CGAL ENABLE_CGAL:BOOL=OFF //Enable GL2PS ENABLE_GL2PS:BOOL=ON //Enable GTS ENABLE_GTS:BOOL=ON //Enable GUI ENABLE_GUI:BOOL=ON //Enable LBM engine (very experimental) ENABLE_LBMFLOW:BOOL=OFF //Enable direct solver for the flow engines (experimental) ENABLE_LINSOLV:BOOL=OFF //Enable liquid control (very experimental), see [Mani2013] for // details ENABLE_LIQMIGRATION:BOOL=OFF //Enable arbitrary precision of bitmask variables (only Body::groupMask // yet implemented) (experimental). Use -DMASK_ARBITRARY_SIZE=int // to set number of used bits (256 by default) ENABLE_MASK_ARBITRARY:BOOL=OFF //Enable OpenMP ENABLE_OPENMP:BOOL=ON //Enable flow engine (experimental) ENABLE_PFVFLOW:BOOL=ON //Enable SPH ENABLE_SPH:BOOL=OFF //Enable VTK ENABLE_VTK:BOOL=ON -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1381282 Title: Sign convention in TriaxialStressController not consistent ? Status in Yet Another Dynamic Engine: New Bug description: Hi, When used as stress or strain rates, sign convention of goal1/2/3 attributes of TriaxialStressController engine seem to me as not consistent. Positive values for stress goals correspond indeed to compression, whereas positive values for goal strain rates involve extension. Which is itself not consistent with TriaxialStressController.strain variable (in the end, to obtain positive TriaxialStressController.strain, you need to set negative strain rates goal variables). Not difficult to fix, but maybe require a common decision. (I vote myself for geomechanics convention) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1381282/+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
[Yade-dev] [Bug 1381282] Re: Sign convention in TriaxialStressController not consistent ?
** Attachment added: CMakeCache.txt https://bugs.launchpad.net/yade/+bug/1381282/+attachment/4263137/+files/CMakeCache.txt -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1381282 Title: Sign convention in TriaxialStressController not consistent ? Status in Yet Another Dynamic Engine: New Bug description: Hi, When used as stress or strain rates, sign convention of goal1/2/3 attributes of TriaxialStressController engine seem to me as not consistent. Positive values for stress goals correspond indeed to compression, whereas positive values for goal strain rates involve extension. Which is itself not consistent with TriaxialStressController.strain variable (in the end, to obtain positive TriaxialStressController.strain, you need to set negative strain rates goal variables). Not difficult to fix, but maybe require a common decision. (I vote myself for geomechanics convention) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1381282/+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
[Yade-dev] [Bug 1381282] Re: Sign convention in TriaxialStressController not consistent ?
Hi, I'm trying to change this sign convention. I have currently a check test failure in DEM-PFV-check.py : DEM-PFV: unbalanced Qin vs. Qout ( -4.07196227268e-06 vs. 4.07179270687e-06 ) Obvioulsy, the sign convention in triaxial engines seems to have an influence on calculations in FlowEngine. I confess I would prefer not to dive in this code too... Would someone used with this code be able to directly highlight the part of the code (if any) that is directly related to this issue ? Thanks, Jerome -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1381282 Title: Sign convention in TriaxialStressController not consistent ? Status in Yet Another Dynamic Engine: New Bug description: Hi, When used as stress or strain rates, sign convention of goal1/2/3 attributes of TriaxialStressController engine seem to me as not consistent. Positive values for stress goals correspond indeed to compression, whereas positive values for goal strain rates involve extension. Which is itself not consistent with TriaxialStressController.strain variable (in the end, to obtain positive TriaxialStressController.strain, you need to set negative strain rates goal variables). Not difficult to fix, but maybe require a common decision. (I vote myself for geomechanics convention) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1381282/+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
[Yade-dev] [Bug 1381282] [NEW] Sign convention in TriaxialStressController not consistent ?
Public bug reported: Hi, When used as stress or strain rates, sign convention of goal1/2/3 attributes of TriaxialStressController engine seem to me as not consistent. Positive values for stress goals correspond indeed to compression, whereas positive values for goal strain rates involve extension. Which is itself not consistent with TriaxialStressController.strain variable (in the end, to obtain positive TriaxialStressController.strain, you need to set negative strain rates goal variables). Not difficult to fix, but maybe require a common decision. (I vote myself for geomechanics convention) ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1381282 Title: Sign convention in TriaxialStressController not consistent ? Status in Yet Another Dynamic Engine: New Bug description: Hi, When used as stress or strain rates, sign convention of goal1/2/3 attributes of TriaxialStressController engine seem to me as not consistent. Positive values for stress goals correspond indeed to compression, whereas positive values for goal strain rates involve extension. Which is itself not consistent with TriaxialStressController.strain variable (in the end, to obtain positive TriaxialStressController.strain, you need to set negative strain rates goal variables). Not difficult to fix, but maybe require a common decision. (I vote myself for geomechanics convention) To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1381282/+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
[Yade-dev] [Bug 1376047] Re: Capillary files OK ?
Do not know exactly what happened, this was my first archive creation, with Archive Manager... I created another archive, directly with tar (command line). The wiki seems currently down (This site is experiencing technical difficulties), I' attaching here in the meantime. -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1376047 Title: Capillary files OK ? Status in Yet Another Dynamic Engine: Fix Released Bug description: Hi, In the capillary files, I guess the first line correspond to the radii ratio (r = Rmax / Rmin), and should correspond to the r-value in the title of the different files. Am I right ? Because, for r = 1.1 ; 1.25 and 1.5, this is not the case, the first line always contains 1. Am I right to think that it is a mistake ? Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1376047/+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
[Yade-dev] [Bug 1376047] Re: Capillary files OK ?
** Attachment added: CapillaryFiles.tar.gz https://bugs.launchpad.net/yade/+bug/1376047/+attachment/4228610/+files/CapillaryFiles.tar.gz -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1376047 Title: Capillary files OK ? Status in Yet Another Dynamic Engine: Fix Released Bug description: Hi, In the capillary files, I guess the first line correspond to the radii ratio (r = Rmax / Rmin), and should correspond to the r-value in the title of the different files. Am I right ? Because, for r = 1.1 ; 1.25 and 1.5, this is not the case, the first line always contains 1. Am I right to think that it is a mistake ? Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1376047/+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
[Yade-dev] [Bug 1376047] Re: Capillary files OK ?
For info, I uploaded a new version of this file. https://www.yade- dem.org/wiki/File:CapillaryJune2012.tar.gz ** Changed in: yade Status: New = Fix Released -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1376047 Title: Capillary files OK ? Status in Yet Another Dynamic Engine: Fix Released Bug description: Hi, In the capillary files, I guess the first line correspond to the radii ratio (r = Rmax / Rmin), and should correspond to the r-value in the title of the different files. Am I right ? Because, for r = 1.1 ; 1.25 and 1.5, this is not the case, the first line always contains 1. Am I right to think that it is a mistake ? Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1376047/+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
[Yade-dev] [Bug 1376047] Re: Capillary files OK ?
Ok Luc, thanks. The value in this first line is indeed used in the computations, and has to be edited (to correspond to the intended ratio), isn't it ? -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1376047 Title: Capillary files OK ? Status in Yet Another Dynamic Engine: New Bug description: Hi, In the capillary files, I guess the first line correspond to the radii ratio (r = Rmax / Rmin), and should correspond to the r-value in the title of the different files. Am I right ? Because, for r = 1.1 ; 1.25 and 1.5, this is not the case, the first line always contains 1. Am I right to think that it is a mistake ? Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1376047/+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
[Yade-dev] [Bug 1376047] [NEW] Capillary files OK ?
Public bug reported: Hi, In the capillary files, I guess the first line correspond to the radii ratio (r = Rmax / Rmin), and should correspond to the r-value in the title of the different files. Am I right ? Because, for r = 1.1 ; 1.25 and 1.5, this is not the case, the first line always contains 1. Am I right to think that it is a mistake ? Jerome ** Affects: yade Importance: Undecided Status: New -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1376047 Title: Capillary files OK ? Status in Yet Another Dynamic Engine: New Bug description: Hi, In the capillary files, I guess the first line correspond to the radii ratio (r = Rmax / Rmin), and should correspond to the r-value in the title of the different files. Am I right ? Because, for r = 1.1 ; 1.25 and 1.5, this is not the case, the first line always contains 1. Am I right to think that it is a mistake ? Jerome To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1376047/+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] [Branch ~yade-pkg/yade/git-trunk] Rev 4142: Re-write of Yade on GitHub wiki page in sphinx doc.
Quite useful, indeed... All is modified, now ! Le 21/08/2014 19:55, Bruno Chareyre a écrit : On 21/08/14 17:38, Jérôme Duriez wrote: but grepping the source code of all wiki pages is out of my competences at the moment... https://yade-dem.org/wiki/Special:WhatLinksHere/Yade_on_github Page I got after clicking on what links here. HTH :) ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] [Branch ~yade-pkg/yade/git-trunk] Rev 4142: Re-write of Yade on GitHub wiki page in sphinx doc.
Ok. May we (I) suppress the wiki content ? Le 20/08/2014 20:04, Bruno Chareyre a écrit : This is great Jerome! The link should also be updated in the programmer's manual [1]. You could grep Yade_on_github to be sure no old links are left behind. Thanks Bruno [1] https://yade-dem.org/doc/prog.html#hosting-and-versioning On 18/08/14 19:13, nore...@launchpad.net wrote: revno: 4142 committer: Jerome Duriezjerome.dur...@3sr-grenoble.fr timestamp: Mon 2014-08-18 17:34:10 +0200 message: Re-write of Yade on GitHub wiki page in sphinx doc. As discussed during the Grenoble workshop, I'm inserting a new rst file corresponding more or less to Yade on GitHub wiki page. Few extra comments are inserted, and the structure is slightly modified. Obviously all is open to discussion, especially the location as a separate rst file, pointed towards by installation and toc pages. added: doc/sphinx/github.rst modified: doc/sphinx/index-toctree.rst doc/sphinx/installation.rst -- lp:yade https://code.launchpad.net/~yade-pkg/yade/git-trunk Your team Yade developers is subscribed to branch lp:yade. To unsubscribe from this branch go tohttps://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription ___ 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 -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] [Branch ~yade-pkg/yade/git-trunk] Rev 4142: Re-write of Yade on GitHub wiki page in sphinx doc.
Ok, a header in the wiki page was pointing towards sphinx since this morning, it is now moreover in bold font and the link you mention at wiki homepage is changed. There should be no more link towards wiki page from sphinx (at least from any rst file in doc/sphinx folder), but grepping the source code of all wiki pages is out of my competences at the moment... Le 21/08/2014 16:16, Bruno Chareyre a écrit : Make sure nothing is pointing there first (be it from a wiki page or a sphinx page). For instance, the link Quick tutorial for Git/GitHub https://yade-dem.org/wiki/Yade_on_github in wiki frontpage should point to sphinx, just like installation instructions do. After that the page will be orphan. Google will remember it, but nobody can reach it by navigating on the website. Erasing the content is not really needed in the short term, but you can put a header in the page to redirect readers to the new page. Bruno On 21/08/14 10:21, Jérôme Duriez wrote: Ok. May we (I) suppress the wiki content ? Le 20/08/2014 20:04, Bruno Chareyre a écrit : This is great Jerome! The link should also be updated in the programmer's manual [1]. You could grep Yade_on_github to be sure no old links are left behind. Thanks Bruno [1] https://yade-dem.org/doc/prog.html#hosting-and-versioning On 18/08/14 19:13, nore...@launchpad.net wrote: revno: 4142 committer: Jerome Duriezjerome.dur...@3sr-grenoble.fr timestamp: Mon 2014-08-18 17:34:10 +0200 message: Re-write of Yade on GitHub wiki page in sphinx doc. As discussed during the Grenoble workshop, I'm inserting a new rst file corresponding more or less to Yade on GitHub wiki page. Few extra comments are inserted, and the structure is slightly modified. Obviously all is open to discussion, especially the location as a separate rst file, pointed towards by installation and toc pages. added: doc/sphinx/github.rst modified: doc/sphinx/index-toctree.rst doc/sphinx/installation.rst -- lp:yade https://code.launchpad.net/~yade-pkg/yade/git-trunk Your team Yade developers is subscribed to branch lp:yade. To unsubscribe from this branch go tohttps://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription ___ 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 -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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 -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] [Yade-users] [Question #251712]: Two problems for post-processing
Le 16/07/2014 19:58, Bruno Chareyre a écrit : Yade must be be consistent and the convention for strain/stress is traction positive. If python says -1 then paraview should also say -1, not +1. I'm learning it... For me there was still different conventions among the different contact laws, with sometimes (in usual cases, at least for me) positiv compression states E.g : O.bodies.append(sphere([0,0,2],1.1)) O.bodies.append(sphere([0,0,0],1.1)) # 2 spheres with an existing overlap = compression O.step() numpy.dot(O.interactions[0,1].phys.normalForce,O.interactions[0,1].geom.normal) = Returns a positiv value. Are you speaking here strictly about strain and stress (and not contact forces/relative displacements) ? (probably yes..) ___ 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] [Branch ~yade-pkg/yade/git-trunk] Rev 4087: Fix compilation.
Sorry Anton... (there was a missing parenthesis ? I confess I relied this time on the buildbot to tell me if there is a mistake, and you were faster than him) The bad point for me is that, now, I'm completely lost about the brace syntax convention Le 17/07/2014 10:14, nore...@launchpad.net a écrit : revno: 4087 committer: Anton Gladky gladky.an...@gmail.com timestamp: Thu 2014-07-17 08:53:17 +0200 message: Fix compilation. modified: pkg/dem/VTKRecorder.cpp -- lp:yade https://code.launchpad.net/~yade-pkg/yade/git-trunk Your team Yade developers is subscribed to branch lp:yade. To unsubscribe from this branch go to https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] [Yade-users] [Question #251712]: Two problems for post-processing
Hello,
Thanks for comments, second commit (*) should solve your remarks 1 and 5.
For 2, I will avoid to answer saying that I do not use REC_STRESS, so I
do not know what should be the best name... (your C corresponds to
Concrete ? or something completely different ?)
For 3, indeed the full matrix is not available (see also below)
For 4, I get your idea, but at the moment I do not know how to store
matrices in vtkDoubleArray... I even have the feeling, according to
vtkDoubleArray.h that this is not possible ? (And at least, there is no
other example than scalar and tuple in current code, no ?)
(*) :
https://github.com/yade/trunk/commit/ee881f8cae6551ae8549de0132a9f74d5ab55576
Le 16/07/2014 14:04, Bruno Chareyre a écrit :
Thanks Jerome, it was the good way to proceed I think. I have a few
comments/suggestions:
1- Please don't use french names for variables, even in the c++ code
(valPropres).
2- We should now remame REC_STRESS - REC_CSTRESS, no?
3- it seems the most used data (matrix in x,y,z) is still not available,
isn't it possible to include it also the output in the form of a matrix
(maybe with a separate flag are all together if BSTRESS)?
4- You can output eigen values and directions in the form of vector3 +
matrix, it would save a lot of lines of code, then in paraview you can
always select individual components.
5- For braces, we tend to use this when possible:
section {
bla;}
instead of
section
{
bla;
}
Combining 3 and 4, your 65 lines (466-530) could fit in maybe 10 lines,
which will be a lot easier to browse and read.
Bruno
On 16/07/14 13:47, Jérôme Duriez wrote:
Question #251712 on Yade changed:
https://answers.launchpad.net/yade/+question/251712
Jérôme Duriez posted a new comment:
Hi,
See
https://github.com/yade/trunk/commit/939e3d771bd6978da2bb16833a535eebd4eb6043
for this commit.
It includes a new recorder (yet another one..) in VTKRecorder:
bstresses to generate scalar data for principal stresses, and
arraydata for principal directions, in sphere...s VTK files. See the
doc.
Tell me if something is wrong...
--
Jérôme Duriez
Post-Doctorant UJF
Laboratoire 3SR
Bureau E139 - 04.56.52.86.30
___
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] [Yade-users] [Question #251712]: Two problems for post-processing
Le 16/07/2014 18:07, Anton Gladky a écrit : 2014-07-16 18:04 GMT+02:00 Jérôme Duriez jerome.dur...@3sr-grenoble.fr: For 4, I get your idea, but at the moment I do not know how to store matrices in vtkDoubleArray... I even have the feeling, according to vtkDoubleArray.h that this is not possible ? (And at least, there is no other example than scalar and tuple in current code, no ?) Just -SetNumberOfComponents(9) and you can store all of your 9 values. Anton Yes, indeed... From my point of view, it would make the exploitation with Paraview more painfull (because there will be the need to refer each time to the sort convention to build this 1D data set from the matrix - 2D data set, and because it will require to construct e.g. arrows from only a part of these big EigenDirections data set, which require more Paraviews manipulations..) Since these reasons might not apply to more computer-friendly guys (..), I can try to improve again; but probably this won't be at the head of my TODO list. ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] [Branch ~yade-pkg/yade/git-trunk] Rev 4062: Correction of some broken sphinx links: yade._utils = yade.utils
Hello everyone, As you might see, I tried to correct some broken links. They were defined in rst source with yade._utils.something, and redirected to web pages with URL like yade._utils.html#yade._utils.kineticEnergy which do not exist, leading to an Error 404 While other links defined with yade.utils.__ (without underscore), leading to yade.utils.html#yade.utils.___ work But in fact, the correct URL, e.g. for kineticEnergy, ends with yade.utils.html#yade._utils.kineticEnergy : note the absence of underscore in the yade.utils.html part, while there is one underscore at the end of the URL... So, now, the situation is a bit improved: there is no more Error 404. Hyperlinks from kineticEnergy redirect to yade.utils.html#yade.utils.kineticEnergy (no underscore at all) This opens indeed the yade.utils module page, but do not lead to the right line (the one of kineticEnergy), because of the missing underscore at the final part of the URL... Does someone know how to deal with these two different yade._utils, yade.utils modules to define correct hyperlinks in the doc ? (Who said it's a detail ? ) Jérôme Le 10/07/2014 13:17, nore...@launchpad.net a écrit : revno: 4062 committer: Jerome Duriez jerome.dur...@3sr-grenoble.fr timestamp: Thu 2014-07-10 11:14:35 +0200 message: Correction of some broken sphinx links: yade._utils = yade.utils modified: doc/sphinx/user.rst -- lp:yade https://code.launchpad.net/~yade-pkg/yade/git-trunk Your team Yade developers is subscribed to branch lp:yade. To unsubscribe from this branch go to https://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] Constitutive laws
Hi, Many thanks to the guy who in fact updated Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity for me ! I had only to add the name of the example script... So, I edited my one (or even two) lines in the wiki page. I do not know how much you were serious about your 2/ proposition, Bruno (this could be a project for a computer science student ?), but let us hope that this day will come. Otherwise I have no doubt that the destiny of this page is to be most of the time deprecated. We just had another example with Law2_ScGeom_ViscElPhys_Basic, with guys that are nevertheless quite involved in Yade... (there is an euphemism there) Jérôme Le 23/05/2014 13:21, Bruno Chareyre a écrit : Hi Jerome, Thank you for suggestions. First, I'm glad you recognize that the functors table is less puzzling than the inheritance diagram (or let's say, they have different purpose). I saw many situations where users would come with a very specific question, then we realize that they picked a wrong contact law (bugged and/or unmaintained, L3 to name one). Frustrating for users, wasted time for everyone. It was the reason to write this table. Another possible solution would be to reduce the total number of functors. For instance eliminate from the source code every law which results at least partly from code duplication, and/or has no example script, and/or is not documented, and/or has no known maintainer. Now, your message is twofold: 1/ where this content should be, and 2/ what this content should be. 1/ If someone could re-type this wiki page in rst format, he would have his karma increased. The right place to put it is in place of this warning, which currently links to the wiki page: https://yade-dem.org/doc/user.html#law2-functor-s Obviously, writing the table in rst will not escape the need to put information in two different places: class documentation and user manual (actually it may be easier to modify a table in a wiki page compared to rst+github, but still I would like the rst option). So: 2/ If someone could write a program that would heuristicaly fill the columns of the table by browsing bug reports, frequency and authors of commits to each law, and bibliographic reference mentionned in the class documentation (warning: references to original papers like Cundall1979 should not appear in the publications column, it needs a semantic analysis of the docstrings), his karma would not only explode, I would also pay him. Before this happens, laws will be orphan until somebody will vouch for them and update the documentation (thank you for updating NormalInelasticity, now you know you need to put an example script). Thank you for raising this need for updates. It actually reminded me to ping Anton and Raphaël for Law2_ScGeom_ViscElPhys_Basic, which still looks red. Could you please guys do something? Thanks Bruno On 23/05/14 10:09, Jérôme Duriez wrote: Hi, This wiki page makes me puzzled since I stumbled upon it. Is there really a consensus to consider this page as really usefull, and *efficient* ? Surely, it could be useful for new users that discover the diagram of https://www.yade-dem.org/doc/yade.wrapper.html#lawfunctor... But, I tend to answer no about the relevance. For me, sphinx doc is the best interface between users and the code (the best place to put documentation !) *and the most easy to maintain*. Each change in the sphinx doc follows the git procedure, with possible control from all developpers and history. Probably such collaborative work features are also be possible with the wiki, but why would we sum / mix the tools ? For example, the authors of the wiki page designated Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity as orphan and colored it in red... Sure, it is up to class authors (me, here..) to correct such things, but I wrote a description, with publications and example script in (*).*Why should I/we re-type it in the wiki page ?* Let us focus on sphinx doc, so that it corresponds to / explains as best as possible the c++ code. This is already a great challenge, maybe there is no need to have to maintain wiki pages about the same subjects ? Jérôme (*) : https://www.yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity Le 22/05/2014 18:24, Christian Jakob a écrit : Hi, I updated the wiki for constitutive laws [1]. Please check for mistakes and add missing informations (examples, dev. status, active users, ...). I detected a duplicate in law description in [2] and [3], which are exactly the same. Can someone fix that, please? Regards, Christian [1] https://yade-dem.org/wiki/ConstitutiveLaws#Constitutive_laws [2] https://yade-dem.org/doc/yade.wrapper.html?highlight=cohesion#yade.wrapper.Law2_ScGeom6D_CohFrictPhys_CohesionMoment [3] https://yade-dem.org/doc/yade.wrapper.html?highlight=cohesion
Re: [Yade-dev] Constitutive laws
So, I have a proposal, introducing two new attributes : One would be LawFunctor.status in ... LawFunctor. Here is a possible c++ implementation in LawFunctor.hpp ((bool, status,0,,boolean expressing the status of the considered LawFunctor. The use is safe if status=True (law validated, support might come from mailing list..), whereas for status=False, no warranty exists that the law is validated and/or maintained/used by anyone else. A warning, see InteractionLoop.Law2warning, is displayed in this case.)) The idea is to put in InteractionLoop something like (please apologize possible syntax mistakes) : if (LawFunctor-status==False) cout/cerr You're using a non validated constitutive law ! Please consider using another LawFunctor with status = True (e.g. Law2_ScGeom_FrictPhys_CundallStrack), unless you are 100% autonom; This warning would display at each iteration, so that users necessarily see it. To not bother 100% autonom people, here comes the second attribute : InteractionLoop.Law2warning ! Wich has such a c++ implementation, in InteractionLoop.hpp, for example : ((bool,Law2warning,1,,Autonom people that use constitutive laws with status=0 may set this attribute to False to get rid of related warnings.)) In this framework : - For what concerns the devs, we get rid of the wiki page. Devs would only have to take care of defining correctly the value of their status, rather than painting in green or red in the wiki page. All other informations such as description, publications, example scripts, should be already in the sphinx doc (If not, such infos would probably be neither on the wiki). There would be no risk of deprecation of the wiki page compared to c++ code. If new laws are commited, it is easy to check which status value is defined in the commit. - For users, the warning of https://www.yade-dem.org/doc/user.html#law2-functor-s would be rephrased, to put attention of users on LawFunctor.status, rather than pointing towards the wiki page. Users that did not read nor this warning, nor the doc of their Law and pick unfortunately a red Law2 would be bored by the warning, and quickly would use e.g. Law2_ScGeom_FrictPhys_CundallStrack, before asking useless questions. Among the drawbacks, I confess that there is no synthetic presentation with such design, compared with the coloured table of the wiki. But maybe this could be generated automaticcaly, grepping for status,1 in the code ? And I consider in any case, that an up-to-date not so synthetic information is better that a deprecated synthetic one... Tell me what you think ! Jérôme Le 26/05/2014 11:06, Bruno Chareyre a écrit : 2/ is very unlikely to happen. More realistic is to translate the table in *.rst. I was secretely hopping that you would be volunteer for that. :) Besides, I'm open to suggestions on how to improve. B On 26/05/14 10:19, Jérôme Duriez wrote: Hi, Many thanks to the guy who in fact updated Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity for me ! I had only to add the name of the example script... So, I edited my one (or even two) lines in the wiki page. I do not know how much you were serious about your 2/ proposition, Bruno (this could be a project for a computer science student ?), but let us hope that this day will come. Otherwise I have no doubt that the destiny of this page is to be most of the time deprecated. We just had another example with Law2_ScGeom_ViscElPhys_Basic, with guys that are nevertheless quite involved in Yade... (there is an euphemism there) Jérôme Le 23/05/2014 13:21, Bruno Chareyre a écrit : Hi Jerome, Thank you for suggestions. First, I'm glad you recognize that the functors table is less puzzling than the inheritance diagram (or let's say, they have different purpose). I saw many situations where users would come with a very specific question, then we realize that they picked a wrong contact law (bugged and/or unmaintained, L3 to name one). Frustrating for users, wasted time for everyone. It was the reason to write this table. Another possible solution would be to reduce the total number of functors. For instance eliminate from the source code every law which results at least partly from code duplication, and/or has no example script, and/or is not documented, and/or has no known maintainer. Now, your message is twofold: 1/ where this content should be, and 2/ what this content should be. 1/ If someone could re-type this wiki page in rst format, he would have his karma increased. The right place to put it is in place of this warning, which currently links to the wiki page: https://yade-dem.org/doc/user.html#law2-functor-s Obviously, writing the table in rst will not escape the need to put information in two different places: class documentation and user manual (actually it may be easier to modify a table in a wiki page compared to rst+github, but still I would like the rst option). So
Re: [Yade-dev] Constitutive laws
Hi, This wiki page makes me puzzled since I stumbled upon it. Is there really a consensus to consider this page as really usefull, and *efficient* ? Surely, it could be useful for new users that discover the diagram of https://www.yade-dem.org/doc/yade.wrapper.html#lawfunctor... But, I tend to answer no about the relevance. For me, sphinx doc is the best interface between users and the code (the best place to put documentation !) *and the most easy to maintain*. Each change in the sphinx doc follows the git procedure, with possible control from all developpers and history. Probably such collaborative work features are also be possible with the wiki, but why would we sum / mix the tools ? For example, the authors of the wiki page designated Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity as orphan and colored it in red... Sure, it is up to class authors (me, here..) to correct such things, but I wrote a description, with publications and example script in (*).*Why should I/we re-type it in the wiki page ?* Let us focus on sphinx doc, so that it corresponds to / explains as best as possible the c++ code. This is already a great challenge, maybe there is no need to have to maintain wiki pages about the same subjects ? Jérôme (*) : https://www.yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Law2_ScGeom6D_NormalInelasticityPhys_NormalInelasticity Le 22/05/2014 18:24, Christian Jakob a écrit : Hi, I updated the wiki for constitutive laws [1]. Please check for mistakes and add missing informations (examples, dev. status, active users, ...). I detected a duplicate in law description in [2] and [3], which are exactly the same. Can someone fix that, please? Regards, Christian [1] https://yade-dem.org/wiki/ConstitutiveLaws#Constitutive_laws [2] https://yade-dem.org/doc/yade.wrapper.html?highlight=cohesion#yade.wrapper.Law2_ScGeom6D_CohFrictPhys_CohesionMoment [3] https://yade-dem.org/doc/yade.wrapper.html?highlight=cohesion#yade.wrapper.Law2_ScGeom6D_InelastCohFrictPhys_CohesionMoment ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] New Yade release 10-11 of May
Hello, Le 08/05/2014 16:37, Matthias Frank a écrit : yadedaily gravityLoading.py Welcome to Yade 1.07.0-180-788bc5d~trusty TCP python prompt on localhost:9000, auth cookie `uyacke' XMLRPC info provider on http://localhost:21000 Running script gravityLoading.py Traceback (most recent call last): File /usr/bin/yadedaily, line 178, in runScript execfile(script,globals()) File gravityLoading.py, line 16, in module O.bodies.append(ymport.text(packing+'.spheres',scale=1.,shift=Vector3(0,0,0),material=sphereMat)) File /usr/lib/x86_64-linux-gnu/yadedaily/py/yade/ymport.py, line 103, in text return textExt(fileName=fileName,format='x_y_z_r',shift=shift,scale=scale,**kw) File /usr/lib/x86_64-linux-gnu/yadedaily/py/yade/ymport.py, line 25, in textExt infile = open(fileName,r) IOError: [Errno 2] File or Directory not found: 'parallellepiped_10_persistentPlane30Deg.spheres' I would not consider this one as a bug. This missing file is generated by another script that has to be launched before trying gravityLoading.py. The workflow of this example (commited by Luc Scholtès) may appear rather complicated but is described in README file of the folder. Note that I proposed a gravityBis example, that is more straightforward. (https://github.com/yade/trunk/commit/4788d0eeb50f5606c9f3fd8c9e3dd71987ee885f) Jérôme ___ 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 1112763] Re: interaction not detected in a VERY specific (body size = period size) case
Maybe the previous fix is incomplete : efficient for initial situation, but not for contacts created during simulation ? (see l.513-514). Will try to investigate more -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1112763 Title: interaction not detected in a VERY specific (body size = period size) case Status in Yet Another Dynamic Engine: Confirmed Bug description: Details and script here, thanks Julia: https://answers.launchpad.net/yade/+question/220785 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1112763/+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
[Yade-dev] [Bug 1112763] Re: interaction not detected in a VERY specific (body size = period size) case
Hi I'm attaching a new version of InsertionSortCollider that could solve this bug. At least, it solves https://answers.launchpad.net/yade/+question/246392 (I have now 9 sphere-box interactions in any case !!!). I think that the problem was caused by the wrap of bound extents inside cells. I disabled this wrapping for big bodies, in case allowBiggerThanPeriod Since it is a quite central piece of code, and because I did not get 100% of InsertionSortCollider, I do not commit it directly, to avoid stress to anyone. But, as I said, it solves my problem, so it might be useful. (In the end, the detail of extent-threshold is still to be discussed, I used 0.99, as in l.500, but l.534 speaks about a half of the period.) Jérôme ** Attachment added: InsertionSortCollider.cpp https://bugs.launchpad.net/yade/+bug/1112763/+attachment/4099567/+files/InsertionSortCollider.cpp -- You received this bug notification because you are a member of Yade developers, which is subscribed to Yade. https://bugs.launchpad.net/bugs/1112763 Title: interaction not detected in a VERY specific (body size = period size) case Status in Yet Another Dynamic Engine: Confirmed Bug description: Details and script here, thanks Julia: https://answers.launchpad.net/yade/+question/220785 To manage notifications about this bug go to: https://bugs.launchpad.net/yade/+bug/1112763/+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] [Branch ~yade-pkg/yade/git-trunk] Rev 3921: Add of an external reference, about the derivation of bodyStressTensor
Hi, I had the feeling that this derivation was directly taken from the paper I cited, that's why I added the reference. I was wondering, but did not know (...), if this paper itself re-explained classical results. In this case I understand that it is removed. Le 15/04/2014 18:56, Bruno Chareyre a écrit : Hi Jerome, I reverted, sorry. There is no reason for an external reference when the documentation gives full details, as it is the case here. I didn't see anything more in the paper you cited. Moreover, I don't like citing a recent paper for something that is in every books on continuum mechanics. OTOH, I added a note and reference on the definition of per-particle bulk stress. Bruno On 15/04/14 16:13, nore...@launchpad.net wrote: revno: 3921 committer: Jerome Duriezjerome.dur...@3sr-grenoble.fr timestamp: Tue 2014-04-15 15:55:10 +0200 message: Add of an external reference, about the derivation of bodyStressTensor modified: doc/references.bib doc/sphinx/references.bib py/_utils.cpp -- lp:yade https://code.launchpad.net/~yade-pkg/yade/git-trunk Your team Yade developers is subscribed to branch lp:yade. To unsubscribe from this branch go tohttps://code.launchpad.net/~yade-pkg/yade/git-trunk/+edit-subscription ___ 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 -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] Fwd: buildbot failure in Yade on yade-full
I just tried, and in fact no...The compilation is successfull on my PC. Le 28/03/2014 12:14, Bruno Chareyre a écrit : I can't reproduce the compile error on my PC. This is weird. When you compile, Jerome, does it give an error? B On 27/03/14 17:07, Jérôme Duriez wrote: Hi, I got this mail after a little commit, I'm on the blamelist :-( But the errors concern apparently (see the full details) lib/triangulation/PeriodicFlow.hpp: that I normally did not modify (which seems to be confirmed byhttps://github.com/yade/trunk/commit/7ab458b4f30d060068fe4dd4e4414b1d52a088ab) And, according to previous build data (https://yade-dem.org/buildbot/one_line_per_build), the (same) buildboot failure was indeed present before my commit. So, we agree that my family will not be damned for ages ?... Jérôme Message original Sujet: buildbot failure in Yade on yade-full Date : Thu, 27 Mar 2014 16:39:03 +0100 De :build...@yade-dem.org Pour : jerome.dur...@3sr-grenoble.fr Copie à : service.i...@3sr-grenoble.fr The Buildbot has detected a failed build on builder yade-full while building yade. Full details are available at: https://yade-dem.org/buildbot/builders/yade-full/builds/2359 Buildbot URL:https://yade-dem.org/buildbot/ Buildslave for this Build: r0calcul5 Build Reason: scheduler Build Source Stamp: [branch master] 7ab458b4f30d060068fe4dd4e4414b1d52a088ab Blamelist: Jerome Duriezjerome.dur...@3sr-grenoble.fr BUILD FAILED: failed compile sincerely, -The Buildbot ___ 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 -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP Lab. 3SR BP 53 38041 Grenoble cedex 9 Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ 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 -- Jérôme Duriez Post-Doctorant UJF Laboratoire 3SR Bureau E139 - 04.56.52.86.30 ___ 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] Fwd: buildbot failure in Yade on yade-full
Hi, I got this mail after a little commit, I'm on the blamelist :-( But the errors concern apparently (see the full details) lib/triangulation/PeriodicFlow.hpp: that I normally did not modify (which seems to be confirmed by https://github.com/yade/trunk/commit/7ab458b4f30d060068fe4dd4e4414b1d52a088ab) And, according to previous build data (https://yade-dem.org/buildbot/one_line_per_build), the (same) buildboot failure was indeed present before my commit. So, we agree that my family will not be damned for ages ?... Jérôme Message original Sujet: buildbot failure in Yade on yade-full Date : Thu, 27 Mar 2014 16:39:03 +0100 De :build...@yade-dem.org Pour : jerome.dur...@3sr-grenoble.fr Copie à : service.i...@3sr-grenoble.fr The Buildbot has detected a failed build on builder yade-full while building yade. Full details are available at: https://yade-dem.org/buildbot/builders/yade-full/builds/2359 Buildbot URL: https://yade-dem.org/buildbot/ Buildslave for this Build: r0calcul5 Build Reason: scheduler Build Source Stamp: [branch master] 7ab458b4f30d060068fe4dd4e4414b1d52a088ab Blamelist: Jerome Duriez jerome.dur...@3sr-grenoble.fr BUILD FAILED: failed compile sincerely, -The Buildbot ___ 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
