yade-dev team mailing list archive

[Luc Scholtes <lscholtes63@xxxxxxxxx>]

Hi guys,
Just a remark: the latest fix seems to solve the random behavior observed
several months ago with the FlowEngine:
https://answers.launchpad.net/yade/+question/659557
This is great :)
However, now, DFNFlow does not give the expected behavior: it seems that
the fractured cells are not identified correctly.
I'll try to work on it asap.
Best
Luc

2018-02-14 15:12 GMT+01:00 Janek Kozicki (yade-dev) <janek_listy@xxxxx>:

> This is awesome. Thank you very much. I have just compiled the latest
> version, and I confirm that DEM-PFV test works.
>
> Finding uninitialized variables can be a super difficult job, hence:
> congratulations! And I must say that I am surprised why there was no
> warning about this variable. I specifically fixed all the remaining
> warnings in my second commit, just in hope of avoiding this kind of
> situation. The only warnings that I get right now are from external
> libraries: vtk and numpy. There must be some missing compiler flag, which
> allowed this uninitialized variable without a warning. Maybe we could try
> to find this missing compiler flag to enable uninitialized warning. Or
> maybe the problem was that this part of code was not instatinated in time
> when the warning could trigger.
>
> Regarding the checkPolyhedraCrush.py, for the time being I have locally
> (without a commit) commented out those four lines of code at the end which
> invoke O.Run(). That makes all tests to pass and debian package is
> successfully built. Of course I am not committing this commenting out. We
> need to think about this a bit. For the moment I am only 100% sure that the
> problem is due to CGAL 4.11, because it always works in 4.9. If we cannot
> fix this, then perhaps we release yade with cgal 4.11 support, but without
> polyhedra crush support.
>
> best regards
> Janek
>
> On 14 Feb 2018, 11:19 +0100, Bruno Chareyre <bruno.chareyre@grenoble-inp.
> fr>, wrote:
>
> Hi Robert,
> Congrats for finding the bug and thanks for fixing.
>
> On 02/13/2018 11:55 PM, Robert Caulk wrote:
>
> the issue was compiler related. GCC 5.4 on ubuntu 16.04 initialized
> factorizeOnly to false by default, while GCC 7.2 on ubuntu 18.04 did
> not do this.
>
>
> That's a good example of "undefined" behavior when using non-initialized
> variables... Definitely a nasty bug.
>
> Therefore, the only necessary change ended up being the explicit
> initialization of factorizeOnly=false.
>
> Indeed. :)
>
> In addition to the bug fix, I edited the solvers so flow.useSolvers=3
> and 4 can now be used with the default CPU build. I can confirm that
> flow.useSolver=4 enables multicore CPU factorization, while
> flow.useSolver=3 sticks to 1 core factorization :-).
>
> Excellent. FYI multicore CPU factorization was faster than single core
> in my benchmarks, but multicore solve phase (using the factorized form)
> was not, it was even a bit slower than single core. Hence the distinct
> attributes  numFactorizeThreads and numSolveThreads.
> Cheers
>
> Bruno
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp
>
>