Project

General

Profile

Bug #1153

inconsistency error triggered in GPU neighbor search

Added by Szilárd Páll about 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
mdrun
Target version:
Affected version - extra info:
4.6.1-dev
Affected version:
Difficulty:
uncategorized
Close

Description

A recent commit (8d6cc14) introduced a bug which can trigger a software inconsistency error in certain cases.

The bug is consistently reproducible using 8d6cc14 with the attached tpr when running with domain-decomposition (two or more MPI ranks) and GPU mode, including emulation.

Program mdrun, VERSION 4.6.1-dev-20130218-8d6cc14
Source code file: /home/pszilard/projects/gromacs/gromacs-gpu/src/mdlib/nbnxn_search.c, line: 688

Software inconsistency error:
Lost particles while sorting

topol_verlet.tpr.bz2 (1.94 MB) Szilárd Páll, 02/20/2013 04:13 AM

Associated revisions

Revision bdcca19a (diff)
Added by Berk Hess about 4 years ago

fixed recent bug with sorting atoms for GPUs

The sort buffer in the nbnxn gridding for GPUs was made too small
in 8d6cc146. This led to inconsistency errors (not incorrect output).
This is fixed and the sort_atoms call is now made simpler and
multiple consistency checks are now always on in debug builds.
Fixes #1153

Change-Id: Ifcdf45bb4de88e7584628d3ed2699e2fd469d5c6

Revision 9b399648 (diff)
Added by Berk Hess almost 4 years ago

fixed recent bug with sorting atoms for GPUs

The sort buffer in the nbnxn gridding for GPUs was made too small
in 8d6cc146. This led to inconsistency errors (not incorrect output).
This is fixed and the sort_atoms call is now made simpler and
multiple consistency checks are now always on in debug builds.
Fixes #1153

Change-Id: Ifcdf45bb4de88e7584628d3ed2699e2fd469d5c6

History

#1 Updated by Berk Hess about 4 years ago

  • Status changed from New to In Progress

#2 Updated by Szilárd Páll almost 4 years ago

  • Affected version set to 4.6.1

The fix has been merged and this open bug contributes to the slightly bizarre 78% "not done" state of 4.6.1. Can this be closed?

#3 Updated by Mark Abraham almost 4 years ago

  • Status changed from In Progress to Resolved

#4 Updated by Berk Hess almost 4 years ago

  • % Done changed from 0 to 100

#5 Updated by Szilárd Páll over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF