Grompp errors with v2024.3: The drift estimate should be a finite value

GROMACS version: 2024.3
GROMACS modification: No

Having installed the latest version of gmx, I get a grommp error on input files that work fine with previous versions:

Program:     gmx grompp, version 2024.3
Source file: src/gromacs/mdlib/calc_verletbuf.cpp (line 853)
Function:    energyDrift(gmx::ArrayRef<const VerletbufAtomtype>, const gmx_ffparams_t*, real, const pot_derivatives_t&, const pot_derivatives_t&, const pot_derivatives_t&, real, real, real, int, real)::<lambda()>

Assertion failed:
Condition: std::isfinite(drift_tot)
The drift estimate should be a finite value

I don’t believe there is an issue with the input files and I cannot spot anything in the 2024.3 release notes that relates to this error.
To check this, I installed version 2024.2 using the same cmake flags:
-DGMX_GPU=CUDA -DCMAKE_INSTALL_PREFIX=/XXX/gmx_mpi_cuda_fftw -DGMX_MPI=on -DGMX_FFT_LIBRARY=fftw3 -DCMAKE_CUDA_COMPILER=/usr/local/cuda-12.4/bin/nvcc

grompp’ing the same input files with this earlier version works just fine. I note that mdrun and other gromacs functions work fine.

I have verified that this is not an issue with gmx_mpi by executing grompp using a serial version generated using the flags:
-DGMX_GPU=off -DCMAKE_INSTALL_PREFIX=/XXX/gmx-serial -DGMX_MPI=off

The gromacs serial executable for v 2024.3 gave the same error.

Is this a bug or has there been an update which requires changes to input files when running grompp?

My mdp file for a simulation where I am relaxing a system before a production run is as follows,

; Run parameters
integrator              = md        
nsteps                  = 5000000 
dt                      = 0.001     
comm-mode               = linear    
; Output control
nstxout                 = 100000    
nstvout                 = 0        
nstfout                 = 0       
nstenergy               = 1000    
nstlog                  = 1000     
nstxout-compressed      = 10000    
compressed-x-grps       = System   
; Bond parameters
continuation            = no        
constraint_algorithm    = lincs     
constraints             = h-bonds   
lincs_iter              = 1      
lincs_order             = 4     
; Neighborsearching
cutoff-scheme           = Verlet  
ns_type                 = grid    
nstlist                 = 10      
rcoulomb                = 0.9      
rvdw                    = 0.9  
lj-pme-comb-rule        = Lorentz-Berthelot
; Electrostatics
coulombtype             = PME      
pme_order               = 4      
fourierspacing          = 0.10   
; Temperature coupling is on
tcoupl                  = V-rescale            
tc-grps                 = Water Ion Other  
tau_t                   = 0.1   0.1  0.1     
ref_t                   = 298   298  5     
; Pressure coupling is on
pcoupl                  = Parrinello-Rahman    
pcoupltype              = isotropic          
tau_p                   = 1.0               
ref_p                   = 1.0             
compressibility         = 4.5e-5      
freezegrps              = a_10      
freezedim               = y y y      
; Periodic boundary conditions
pbc                     = xyz     
periodic_molecules      = yes
; Dispersion correction
DispCorr                = EnerPres  
; Velocity generation
gen_vel                 = no      

@hess, do you have any idea what might be the issue? It sounds like a bug to me.

There must be a bug somewhere, you should never get an assertion failure. I added this assertion in 2024.3.

My guess is then that with 2024.2 you get a Verlet buffer of zero. This assertion is there to catch such issues. I fixed an issue causing infinite drift estimates when large masses were present. But apparently there is another issue.

Could you file an issue on gitlab with all input to run grompp?

Thanks for the updates.

As requested, I have created issue #5222 on GitLab.

To report back, I found the issues and uploaded a fix. I hope it makes it into 2024.4.

You can work around this for the moment by settings verlet-buffer-tolerance=-1 and nstlist and rlist manually. But that will give somewhat worse performance. And lowering the 2200 mass to something around 400 would avoid the issue.

Thanks for the workaround - it’s good to know that this wasn’t a problem I had somehow created.

PS The large mass was introduced to slow atom diffusion during this relaxation step and it works quite well to avoid the dissolution of crystal seeds (as well as modifying the potential) before seeding simulations are performed in NVT.