<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><div style="text-align: left;"><br></div><br><br><br><hr id="stopSpelling">> Date: Thu, 27 Mar 2008 07:54:03 +0100<br>> From: spoel@xray.bmc.uu.se<br>> To: gmx-users@gromacs.org<br>> Subject: Re: [gmx-users] minimization -- bugzilla or general advice?<br>> <br>> David Mobley wrote:<br>> > Xavier,<br>> > <br>> >> I was surprised by the value you use for emstep=1.0e-8. This is the<br>> >> "maximum step size" and is in nm! I think that's where your problem is.<br>> > <br>> > I added this recently in testing because I thought perhaps the problem<br>> > could be due to using too large of steps. It does not help. So<br>> > everything I send in my previous e-mail holds true regardless of which<br>> > emstep value I use (default vs 1.0e-8).<br>> > <br>> >> The minimizer is probably incapable to find anything better for your<br>> >> system with this step size and therefore stops.<br>> >><br>> >> Did you try to keep the default value emstep=0.01 nm or something<br>> >> bigger than 1.0e-8?<br>> > <br>> > Also, I think your argument is backwards: steepest descents should<br>> > work better (but slower) the smaller the step size, I think. If steps<br>> > are too big it won't be able to move down the gradients accurately<br>> > enough and risks not being able to find the minimum. The smaller the<br>> > steps are the more accurately it should be able to find the minimum.<br>> > <br>> David,<br>> <br>> if you add 1+1e-8 in float at least the result is 1. Since coordinates <br>> in typical systems are on the order of a few nm such a stepsize does <br>> indeed not make sense, but since you tried larger stepsize as well the <br>> problem is real. The stepsize is used as the maximum displacement along <br>> the force vector in the steep algorithm.<br>> <br>> I encourage you to submit a bugzilla with a few examples.<br><br>The problem could be in the constraints.<br>Gromacs 3 constrains the forces during EM by adding c*f to the coordinates,<br>constraining those and then dividing the constraint displacement by c.<br>This limits the accuracy.<br><br>In Gromacs 4 I have implemented force constraining for LINCS and SETTLE.<br>This seems to improve the accuracy a lot.<br><br>Could you check if using Gromacs 4 solves your problems?<br><br>Berk.<br><br><br /><hr />Express yourself instantly with MSN Messenger! <a href='http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/' target='_new'>MSN Messenger</a></body>
</html>