[Yade-dev] buildbot warnings in Yade on yade-full

[buildbot]

The Buildbot has detected a problem in the build on builder yade-full while 
building Yade.
Full details are available at:
 https://yade-dem.org/buildbot/builders/yade-full/builds/4702

Buildbot URL: https://yade-dem.org/buildbot/

Buildslave for this Build: r0calcul9

Build Reason: The web-page 'rebuild' button was pressed by '': 

Build Source Stamp: 60fcb1bced2eac2f5b20730fb675f3f26655bcb8
Blamelist: 

Build Had Warnings: warnings test test_1

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

[Yade-dev] [Bug 1764424] Re: Segfaults with boost::python::tuple during simulation loop

[Jan Stránský]

Hi Jerome,

to find where the segfault problem comes from, you can run
catchsegv yade script.py
the output tells the last actions before the segfault.
If the output is too long, you can try
catchsegv yade script.py > /tmp/segv.err
or
catchsegv yade script.py 2> /tmp/segv.err
(don't remember) and provde the segv.err file

cheers
Jan

PS: this is exactly the point I mentioned in [1]. If you use these
functions in C++, using boost::python stuff is extra, std::vector should
be used instead of boost::python::tuple and the buust::python stuff
should only be used to interact with Python :-)

[1] https://www.mail-archive.com/yade-
d...@lists.launchpad.net/msg13300.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] buildbot warnings in Yade on yade-full

[buildbot]

The Buildbot has detected a problem in the build on builder yade-full while 
building yade.
Full details are available at:
 https://yade-dem.org/buildbot/builders/yade-full/builds/4701

Buildbot URL: https://yade-dem.org/buildbot/

Buildslave for this Build: r0calcul9

Build Reason: The web-page 'rebuild' button was pressed by '': 

Build Source Stamp: [branch master] 93e2e262e348926fab516dde3dc8b5fc3ddb7df0
Blamelist: bchareyre 

Build Had Warnings: warnings test test_1

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

Re: [Yade-dev] Dynamic vs Fixed for bodies utils functions

[Jerome Duriez]

Thanks for feedback, what did you have in mind with "aliasing" ?
I do not know (nor could find) any Python aliasing thing which I could 
understand as being possibly useful here..


To enable both dynamic and fixed to be accepted, I could only imagine 
for now adding (**kwargs) to the functions signatures.
While this may not harm for _commonBodySetup() (because this function is 
quite transparent from an user's point of view), it would probably be a 
bad thing for sphere() et al. functions (for their documentations at least)




--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 27/07/2018 21:18, Bruno Chareyre wrote:
Hi Jérôme, I discover the situation with your email and I agree that 
it can be improved (looks like).
A good fix would need to clarify the meaning (or is it already clear 
that fixed == !dynamic everywhere?), then it is easy to make both 
accepted through aliasing.

Removing one of the two seems awkward based on your summary.
Cheers
B

Le jeu. 26 juil. 2018 18:07, Jerome Duriez > a écrit :


Hi,

As you may know, the Python (utils module) functions for creating
bodies
make a more or less redundant use of the two "dynamic" and "fixed"
boolean parameters.


It seems to me both are usually accepted with different behaviors:
- for sphere() and box(), both are passed to _commonBodySetup where
/dynamic/ (when given by the user) will rule without mercy over
/fixed/. [1]
- facet(), tetraPoly(), tetra(), polyhedron() also accept both but
makes
no use whatsoever of /dynamic/ ;-)

As a matter of fact, and since one commit in 2010 [2], the /dynamic/
keyword is said to be deprecated but the fact is it is still
here... It
also directly appears in the rest of the code (contrary to
/fixed/) as
Body.dynamic [3] and is commented as such in the doc [4].

On the other hand, the use of fixed seems to be more frequent in the
script examples (I did not try here to distinguish between the
working
examples and the non-working ones ;-) though..)...


In case you agree with my description, would you also agree with some
changes here ?

If yes, my personal choice would be to just keep /dynamic/. Note that
the risks for breaking backwards compatibility for old Python scripts
may be reduced by:
- keeping just the /dynamic/ attribute in _commonBodySetup() which is
never used directly by the users
- removing the fixed parameter from sphere() and box()
- modify the facet(), tetraPoly(), tetra(), polyhedron() code to just
pass /dynamic/ to _commonBodySetup(), possibly keeping the /fi//xed/
name in these functions signatures if you prefer to.
(?)


What are your opinions / use of these keywords ?


Jérôme

[1] https://github.com/yade/trunk/blob/master/py/utils.py#L131
[2]

https://github.com/yade/trunk/commit/d8e420ed569c6b4ec3569282df925a5035513d24
[3]
https://yade-dem.org/doc/yade.wrapper.html#yade.wrapper.Body.dynamic
[4] https://yade-dem.org/doc/user.html#motion-constraints

--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
Mailing list: https://launchpad.net/~yade-dev

Post to     : yade-dev@lists.launchpad.net

Unsubscribe : https://launchpad.net/~yade-dev

More help   : https://help.launchpad.net/ListHelp



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



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

[Yade-dev] Shop::aabbExtrema() : from boost::python::tuple return type to std::vector ?

[Jerome Duriez]

Hi again,

I would like changing in pkg/dem/Shop*pp the py::tuple aabbExtrema() [*] 
to std::vectoraabbExtrema() (keeping obviously the Python 
exposure).



I think this would

- make the Shop C++ files one (small) step closer from the ideal 
situation discussed at 
https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13308.html


- thus avoiding the back and forth Python-C++ boost conversions in all 
C++ uses of aabbExtrema() e.g. [**]


- help me solving easily https://bugs.launchpad.net/yade/+bug/1764424 
;-) (thanks Jan for suggestion)


- change (I guess, after py/wrapper/customConverters.cpp) from the 
user's side the aabbExtrema() value (after typed in YADE terminal) from 
a tuple to a list...



Thoughts ?

Jérôme

[*] https://github.com/yade/trunk/blob/master/pkg/dem/Shop.hpp#L165 and 
https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L874
[**] https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L352 
and L353


--
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21


___
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] buildbot warnings in Yade on yade-full

[buildbot]

The Buildbot has detected a problem in the build on builder yade-full while 
building Yade.
Full details are available at:
 https://yade-dem.org/buildbot/builders/yade-full/builds/4704

Buildbot URL: https://yade-dem.org/buildbot/

Buildslave for this Build: r0calcul9

Build Reason: The web-page 'rebuild' button was pressed by '': 

Build Source Stamp: 949a2d9bd628898f7a3dabf84781e31667487ea8
Blamelist: 

Build Had Warnings: warnings test test_1

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

[Yade-dev] buildbot warnings in Yade on yade-full

[buildbot]

The Buildbot has detected a problem in the build on builder yade-full while 
building yade.
Full details are available at:
 https://yade-dem.org/buildbot/builders/yade-full/builds/4703

Buildbot URL: https://yade-dem.org/buildbot/

Buildslave for this Build: r0calcul9

Build Reason: The web-page 'rebuild' button was pressed by '': 

Build Source Stamp: [branch master] 9c4806102a614ee9043e72a2bb27b4e894c1e1ad
Blamelist: T Sweijen 

Build Had Warnings: warnings test test_1

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