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_li...@wp.pl>: > 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@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
