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.
On 14 Feb 2018, 11:19 +0100, Bruno Chareyre <bruno.chare...@grenoble-inp.fr>,
> 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.
> Mailing list: https://launchpad.net/~yade-dev
> Post to : firstname.lastname@example.org
> Unsubscribe : https://launchpad.net/~yade-dev
> More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~yade-dev
Post to : email@example.com
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp