Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in
O
openmc
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 70
    • Issues 70
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 9
    • Merge Requests 9
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Shikhar Kumar
  • openmc
  • Issues
  • #1214

Closed
Open
Opened Apr 05, 2019 by Shikhar Kumar@shikhark
  • Report abuse
  • New issue
Report abuse New issue

Test failures on Ubuntu 18.10

Created by: paulromano

I recently upgraded my system to Ubuntu 18.10, and one of the first things I discovered was that our test suite seemingly doesn't pass anymore, in particular the following tests:

  • test_cmfd_feed_ng
  • test_quadric_surfaces
  • test_triso

My first thought was that this was due to a new version of gcc (8.2), but even when I install an older version of gcc, the tests still fail. After quite a bit of digging, I was able to track the difference down to an update of glibc (the GNU C standard library) from version 2.27 in Ubuntu 18.04 to version 2.28 in Ubuntu 18.10. In particular, the basic transcendental functions in libm (part of glibc) were heavily refactored in 2.28 to improve performance but actually lost accuracy in the last digit as one of the tradeoffs. This is the best description of the changes I've found so far, and I've confirmed these changes by looking at the glibc source code (there are comments in there that sin and cos are computed within ~0.55 ULP that didn't appear in glibc 2.27). Anyway, the gist of this is that, because this is Monte Carlo, those last digit changes eventually propagate to non-last-digit changes, and given a long enough run (which the three tests I listed are), the simulation will diverge and you end up with different results. There's not a whole lot we can do about it other than to change the parameters for these three tests such that they get close enough results with glibc 2.27 and 2.28. I'll probably look into doing that next...

Reflecting on this a bit, the same reasoning is probably responsible for #801 because macOS uses a different C standard library (libSystem) with, presumably, a different implementation of transcendental functions with a different accuracy in terms of ULP.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
0
Labels
None
Assign labels
  • View project labels
Reference: shikhark/openmc#1214