Well ... I'm facing the same problem. I dont think that changing the geometry relaxation driver will solve the problem ... which is by the way related to how the program is generating the DM. I've been testing a ZnO surface (32 atoms into the supercell) , which I can optimize with the version 2.02 in less than 30 CG steps. With the version 3.0b however the DM goes crazy from the second CG step and on, sometimes generating forces incredible high.
For the sake of science, I've tested other drivers ... but as I said, thats not the problem! Here some points to consider: - By default, the siesta allows just movements of 0.2 Bohr for each atom in each SCF cicle. It was not a problem in using the blind allowance in the old version, but it seems to be in the new one. - Well if you use pre-relaxed structures as initial configuration,everything goes fine (with some good luck), but starting with rough structures (like and unrelaxed surface for example) I got a second SCF cycle with a very bad quality and the whole thing just went crazy. I was attempted to accept the idea that the new version cannot deal with strong relaxations ... but I've tried to perform the calculations with MD.MaxCGDispl = 0.1 Bohr , 0.05 Bohr and 0.01 Borh ( with are considerable small atomic displacements ) and the DMs also went crazy from between the 1.o and the 5.o SCF cicle. The new version seems to fail in handling with the DM, whereas the old scheme worked well. I also turned the DM.AllowExtrapolation off, but the convergence fails anyway (with more than 100 SCF cycles). Switching DM.AllowReuse of makes possible relaxing the structure ... but it is much more expensive than in the version 2.02, just bacause the DM is reinitialized every single CG step. For big calculations beyond testing purposes it is just unfeasible ( remember I´m dealing just with 32 atoms ). Still ... why a completely new "Initial Guest DM" works better than a pre-converged one for a very similar geometry? And why this problems linger even for very small atomic displacements (0.01 Bohr)? I understand that there is a change in the program, and please dont think I'm just criticizing ( I'm giving an honest feed back to you and glad in helping ), but it seems that, at least in the tests I could see, this change is still not mature enough. Kind regards NH PS: I´ve compile both v.2.02 and 3.0b with ( using -O2 and even -O0 ): ifort 10.1.015 mvapicht2 (intel) 1.2.0 Intel MKL 10.0.3.020 Kind regards Ney On Tue, Oct 27, 2009 at 2:39 PM, Alberto Garcia <[email protected]> wrote: > Dear ZhengPing, > > > On Wed, Oct 21, 2009 at 3:12 AM, ZhengPing Fu <[email protected]> wrote: > > Hi, > > I have a similar problem with siesta2.02 and siesta3.0b > > I can relax the coords with siesta2.20 successfully, while I failed with > siesta3.0b for the same > > input file because the scf calculating diverged from some CG step on. > > I didn't find any notable difference between the geometry structure that > got converged scf calculating > > and that got diverged scf calculating. > > The algorithm for extrapolation of the DM accross geometries has > changed in Siesta3.0-b. The divergences > you are seeing might be related to an inadequate extrapolation for a > big geometry change. You might want > to tune the behavior by either: > > - Disabling DM extrapolation, or even the reuse of the DM accross > geometry steps. > - Specifying a maximum step size for the CG algorithm > - Switching to another relaxation algorithm such as quenched MD, or > the similar FIRE algorithm. > > You can find the relevant FDF options in the manual. > > Regards, > > Alberto >
