[molpro-user] MCSCF Convergence and orbital saving.
Alexander Mitrushchenkov
sasha at theochem.uni-stuttgart.de
Wed Jun 20 15:49:38 BST 2007
Luke,
Sorry if I did not read carefully your post. Of course, thresholds are not
linked while global thresholds should (at least expected) to affect also
geometry optimization calls. I'll make a bug report, and eventually this be
fixed. What is sure, is that most of input is ignored (inside MULTI block)
when doing geometry optimization, apart from the very first run. If I
understand properly, this is to avoid jumps causing unphysical behavior.
With occupations, indeed, your specified them. Still, I've seen two commas in
your input, which is not correct if you mean saving orbitals. Correct would
be
orbital,5000.3
[or natorb,5000.3; for natural orbitals ]
(though note that you did not define file 3 to be permanent, so this record
would be lost in any case, did you mean 5000.2?). If you wish to save CI
vectors (which are not used in restart anyway I guess), then it is better to
use explicit form, like
save,ci=5000.2;
or if you wish to save orbital configurations (nothing to do with orbitals!)
then use
save,ref=5000.2;
Please note that any of these (ci or ref) implies the use of CSF CI instead of
determinant CI. Even though manual says that it will be turned on
automatically, it is better to specify explicitly, like
config,csf;
Most probably, what happened indeed in your case is that the two commas caused
the REF to be saved (obsolete form of input) switching on the CSF algorithm
which is less efficient/require much more memory for coupling coefficients.
If this is the case, then I am afraid there is no way to deal with presently,
unless you have more powerful computer with more memory.
Cheers,
Sasha
On Wednesday 20 June 2007 16:14, you wrote:
> Sasha,
>
> Thankyou for your suggestions. The second problem first. I have tried
> placing the gthresh line you suggest just before my basis line. This works,
> again, only if I do not want to do the optimisation. It appears that optg
> overides it. I have not tried changing the value for step. Do you think
> that I will have to change step to get energy threshhold to change, ie, are
> they linked?
>
> On the fist point, I am not sure that I understand what you mean by
> specifying the closed shell occupation. I have a closed card in both the
> restarted calc and the original calc. However, I think that I might not
> have expressed my problem clearly in the original question, so this may not
> apply. I can restart the calculation successfully, provided that I do not
> have the save card. Its presence, somehow caused the aforementioned
> problems.
>
> Thanks again,
>
> Luke
>
> On Wed, 20 Jun 2007, Alexander Mitrushchenkov wrote:
> > Luke,
> >
> > The answer to your first question could be the change in the closed shell
> > occupation, which you can check in the output. In principle, it should be
> > restarted correctly, and I will verify and make a bug report if this is
> > not the case. In the meantime, to avoid problems, you could specify
> > explicitly the number of closed-shell orbitals.
> >
> > For the second question, I guess most of the input for MULTI is ignored
> > when doing a geometry optimization. Specifying the global thresholds
> > should work though, like
> >
> > gthresh,energy=0.2e-6
> >
> > somewhere before and outside of the MULTI input. This is described in
> > section 10.11 of the manual. Please note that you may need to change the
> > threshold for STEP too.
> >
> > Please let us know if this helps.
> >
> > Cheers,
> >
> > Sasha
> >
> > On Wednesday 20 June 2007 13:43, you wrote:
> > > Dear Molpro users,
> > >
> > > I am trying to undertake some MCSCF and MRCI calculations with MOLPRO
> > > 2006.1 patch version 40, but I am having a few problems that I cannot
> > > solve with the help of the manual.
> > >
> > > Firstly,
> > >
> > > When I perform an MCSCF calculation with the following input, the
> > > calculation proceeds normally.
> > >
> > > memory,100,m
> > > file,2,bcl3-min1-mcscf-big.wfu
> > > gprint,orbital=5,basis
> > > r1=1.758 angstroms
> > > r2=1.7581 angstroms
> > > r3=1.758 angstroms
> > > a1=120.01 degrees
> > > a2=120.00 degrees
> > > d1=180.0 degrees
> > > geometry={
> > > B1,
> > > Cl1, B1, r1
> > > Cl2, B1, r2, cl1, a1
> > > Cl3, B1, r3, cl1, a2, cl2, d1
> > > }
> > > basis={default,sto-3g}
> > > {hf
> > > wf,54,1,0}
> > > basis={default,cc-pvtz}
> > > {hf
> > > wf,54,1,0}
> > > {multi
> > > frozen,0,0
> > > closed,13,3
> > > occ,25,7}
> > > optg
> > >
> > > However, when I try to restart the calculation, and save the orbitals,
> > > by using the input
> > >
> > > memory,100,m
> > > file,2,bcl3-min1-mcscf-big.wfu
> > > gprint,orbital=5,basis
> > >
> > > geometry={
> > > B1,
> > > Cl1, B1, r1
> > > Cl2, B1, r2, cl1, a1
> > > Cl3, B1, r3, cl1, a2, cl2, d1
> > > }
> > >
> > > basis={default,cc-pvtz}
> > > {multi
> > > save,,5000.3
> > > frozen,0,0
> > > closed,13,3
> > > occ,25,7}
> > >
> > > the output generates a few new lines of code,
> > >
> > > Maximum number of shells: 8
> > > Maximum number of spin couplings: 429
> > >
> > > And then the following error message:
> > >
> > > Storage for configuration lists 5182008, coupling
> > > coefficients3670869, address lists*******
> > >
> > > Molecular orbitals read from record 2140.2 Type=MCSCF/MULTI
> > > (state 1.1)
> > >
> > > Wavefunction dump at record 2140.2
> > >
> > > Convergence thresholds 0.10E-01 (gradient) 0.11E-05 (energy)
> > > 0.10E-02 (step length)
> > > insufficient memory available - require 162579456
> > > have 15685319
> > > the request was for real words
> > >
> > > GA ERROR fehler on processor 0
> > >
> > > It appears to be that MOLPRO is trying to do some type of spin orbit
> > > calculation(?), which seems to be a lot slower, and requires a lot more
> > > memory than I have available. Can anybody indicate why just saving the
> > > orbitals should cause molpro to behave in this way, and can I do
> > > anything to prevent it? I wish to use the orbitals as the reference for
> > > a CI calculation.
> > > I notice that MOLPRO 2002.3 did not behave in this way - the save
> > > command just caused the same calculation as before to be performed.
> > >
> > > Secondly,
> > >
> > > I would like to change the convergence criterion on the MCSCF energy
> > > calculation during my geometry optimisation. Again, I have consulted
> > > the manual, but I do not seem to have any success with the commands
> > > given.
> > >
> > > My input is as follows:
> > >
> > > memory,100,m
> > > file,2,bcl3-ts5-mcscf-big.wfu
> > > gprint,orbital=5,basis
> > >
> > >
> > > geometry={
> > > B1,
> > > Cl1, B1, r1
> > > Cl2, B1, r2, cl1, a1
> > > Cl3, B1, r3, cl1, a2, cl2, 180.0
> > > }
> > >
> > > basis={default,cc-pvtz}
> > > {multi,
> > > frozen,0,0
> > > closed,13,3
> > > occ,25,7
> > > thresh,energy=0.2e-6}
> > > put,molden,bcl3-ts5-mcscf-big-sp.mld
> > > {optg
> > > root,2
> > > method,qsd
> > > hessian,read}
> > >
> > > The manual also suggests I can use the command "energy" after the multi
> > > command to change the convergence threshold. I have tried:
> > >
> > > multi,energy=0.2e-6
> > >
> > > and
> > >
> > > multi
> > > energy=0.2e-6
> > >
> > > neither of these seem to work. Either the calculation complains about
> > > the syntax, or just carries on with the normal criterion, 0.1e-7.
> > >
> > > I have also tried:
> > >
> > > accuracy,energy=0.2e-6
> > >
> > > in the MULTI command block.
> > >
> > > This is also ignored. Is this problem something to do with the optg
> > > command altering the convergence thresholds after I have changed them?
> > > I believe that the convergence criterion is tighter when performing an
> > > optimisation of the geometry. Can anybody suggest the correct syntax to
> > > use.
> > >
> > > Many thanks in advance for your help, (and sorry for the length of the
> > > enquiry!)
> > >
> > > Luke Thomas
> > > Department of Chemistry
> > > University College London
--
Dr. Alexander Mitrushchenkov
Universität Stuttgart
Institut für Theoretische Chemie
Pfaffenwaldring 55
D-70569 Stuttgart
Tel +49 (0)711 / 685-64409
Fax +49 (0)711 / 685-64442
Mail sasha at theochem.uni-stuttgart.de
More information about the Molpro-user
mailing list