Dear Jason,
Thank you very much for your useful information. I switched the simulation on CPU and it worked successfully! On the other hand, the following equilibration and production steps were performed on GPU architecture without problems.
Thanks again!
-erik-
Dr. Erik Laurini
Department of Engineering and Architecture
University of Trieste, Via Valerio 10, 34127, Trieste (Italy)
Tel. + 39 0405583440
-----Original Message-----
From: Jason Swails [mailto:jason.swails.gmail.com]
Sent: giovedì 25 giugno 2015 16:48
To: AMBER Mailing List
Subject: Re: [AMBER] error in MD simulation
On Thu, Jun 25, 2015 at 10:17 AM, <erik.laurini.di3.units.it> wrote:
> Dear Amber users,
> I'm trying to perform a simulation of a dimeric protein (about 90 aa
> for each chain) solvated using TIP3P water model in a cubic box, total
> number of atoms = 66656. I run the simulations with PMEMD on NVIDIA
> GPU. After the minimization, the calculation crashes with the following error:
>
> cudaMemcpy GpuBuffer::Download failed an illegal memory access was
> encountered At line 137 of file inpcrd_dat.F90 (unit = 9, file =
> 'heat_solv.rst') Fortran runtime error: End of file
>
This looks like the coordinate file was truncated. What are the contents of heat_solv.rst? It also seems strange to me to see *both* of the error messages you printed above in the same simulation. Maybe you saw the cudaMemcpy error in the minimization, and then the heating stage failed because the restart wasn't written?
What version of Amber are you using?
>
> I red in the blog that it could be a restraints problem but I received
> the same error even when I set ntr=0. In attachment you can find the
> input parameters that I tried to use for my simulation...this is only
> the early stage after that I plan to carried out the equilibration in
> NPT and the production in NVT ensemble.
> Could you please help me or give me any advice about this error?
>
Common tips: run minimizations using the CPU code, since fixed-precision numbers can overflow more often than double precision. Whenever you get an error, check the CPU code to see if you get an error there as well. Error messages are usually better when using the CPU code, so that is always a good first step in debugging.
HTH,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jun 26 2015 - 05:30:03 PDT
