Hi everyone...
I'm trying to run a NEB calculation on a solvated system with 52 atoms in the QM region; it does the DFT calculation and solvent optimization for several of the beads and then crashes with:
53:53: * 53: Deviation too large for solvent 483 *:: 483
(rank:53 hostname:mpc0894 pid:4688):ARMCI DASSERT fail. armci.c:ARMCI_Error():260 cond:0
Last System Error Message from Task 53:: Numerical result out of range
It looks like this happens during a solvent minimization phase that has run longer than the previous ones (347 steps), but not as long as specified by maxiter. My input script is:
start react
permanent_dir /home/Ueda-DNA/QBIC/neb/perm
scratch_dir /home/Ueda-DNA/QBIC/neb/scratch
charge -1
basis
C library 6-31G*
H library 6-31G*
N library 6-31G*
O library 6-31G*
end
dft
xc b3lyp
direct
iterations 500
end
md
system react_neb
msa 100
cutoff 1.0
end
qmmm
bqzone 10.0
region solvent
eatoms -1373.8747207761
maxiter 200
ncycles 1
density espfit
xyz neb_out
end
set qmmm:neb_path_limits react_opt.rst prod_ref.rst
set neb:nbeads 20
set neb:stepsize 1.0
set neb:steps 10
task qmmm dft neb
I've seen this problem described in the context of QM/MM optimization (http://www.emsl.pnl.gov/docs/nwchem/nwchem-support/2001/10/0008.Re:_deviation_too_large_fo...), where the recommendation was to try an MM optimization of the starting structure, to arrive at a more reasonable solvent configuration. I'd actually done an extensive QM/MM optimization of my starting coordinates, but (if I understand correctly) the initial bead configurations are a linear interpolation of the qmlink region between the starting and final coordinates, combined with the solvent coordinates from the initial configuration. So, especially for the beads closer to the final coordinates, the initial solvent/solute interactions are inevitably going to be horrible, and the beads near the middle of the trajectory will involve fairly large motions of the atoms in the qm region during optimization.
This seems to be a really common error -- I've probably tried this run about a dozen times now with different initial/final positions, trying out different options, etc. and this is usually what brings it down. Is there a good way to avoid this? My best guess at this point is to try and cook up a set of restart files that won't move as much during minimization rather than using qmmm:neb_path_limits to do the linear interpolation for me.
Any ideas would help a lot.
Thanks,
--craig
|