Here are the coordinates of the 3 atoms that blow up this simulation:
6084: 38.171128 34.601178 39.471302
5507: 38.165383 34.604245 39.467213
28509: 37.811290 33.759249 39.328133
I'd say the minimization is likely blowing up on VDW since I cap forces and
then getting overwhelmingly attracted electrostatically.
Can you try this again with tiny VDW radii on the water atom?
Scott
On Mon, Aug 26, 2013 at 8:15 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
> Hi Jan-Philip
>
>
> >My mail was too long, sorry. Important points:
> >
> >- the min1+min2+heat protocol runs fine with the CPU version, i.e. CPU
> >minimization solves the problem. The crash during heatup, however, also
> >appears in the CPU version when starting from the minimized structure as
> >created by the GPU code.
>
> Well, that explains it - it is simply a limitation of the precision model.
> If you use the SPDP or DPDP version of the GPU code it will likely work
> fine. Ultimately though I think the advice should simply be to carry out
> minimization using the CPU code.
>
> >
> >- the error message in the GPU version can be improved. The CPU version
> >informs about too large velocities. The GPU version just says 'launch
> >failure launching kernel kNLSkinTest'.
>
> This is extremely difficult to do without destroying performance.
> Essentially the advice here is the same as it has always been. If you see
> an unexplained crash on the GPU code try it with the CPU. Either way both
> simulations are wrong - just the error message is more informative on the
> CPU.
>
> >
> >- it is very interesting to understand what is wrong with the structure
> >in min2.rst as created by the GPU version. MOE does not identify
> >clashes, the structure looks fine. Any pointers what I can check to
> >identify the problematic part in this structure?
>
> The structure is simply wrong - end of story. There is nothing really to
> identify here. Essentially the forces are too large, they get truncated
> and the resulting gradient does not match the energy. Thus the
> minimization algorithm gets horribly confused since the change in energy
> that occurs when modifying the structure as indicated by the forces is not
> what it expected. Probably if you just stuck with steepest descent it
> 'might' work but the minimizer will still struggle. I think ultimately we
> should just make the truncation fatal and quit with an error message
> saying the structure is too strained for the GPU, switch to CPU
> minimization. I'll see if I can do this for the next update.
>
> In terms of your initial structure, if you really are interested I would
> dump the force array and look at the atoms with the largest forces. You
> could also take the CPU minimization where on step 1 it should report the
> atom with the highest force (GMax) take a look in the vicinity of that
> atom. It's probably coming from the VDW term. Likely two atoms are just
> inside the VDW radius of each other and the r^12 term here gives a massive
> force.
>
> >> If you are using the
> >> latest version of the code it truncates the forces at the largest
> >> representation that SPFP supports - in most cases this works and will
> >>get
> >> you out of trouble but if your initial structure is too strained it will
> >> also likely break the minimizer.
> >
> >When I read in the changelog that the truncation was implemented in GPU
> >minimization code, I switched back to GPU minimization. For the system
> >in question the mean part is that it 'works' in the sense that the
> >minimization does not quit with an error and the output looks fine.
>
> The truncation was a hack that I hoped would work - for most systems it
> seems to work fine but clearly there are exceptions that I wasn't
> anticipating and the minimizer is not as robust as I was hoping. Thus we
> probably need a bugfix to disable this.
>
> All the best
> Ross
>
>
>
> _______________________________________________
> 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 Mon Aug 26 2013 - 10:30:03 PDT
