[molpro-user] surf and optg problems in Molpro
Matthias Heger
mheger at gwdg.de
Sat Apr 19 20:26:42 BST 2014
Dear Guntram,
I'm afraid I have to bother you again. I've been chasing bugs a little,
since I still got the "Record 1650" error even when using the input you
suggested and starting from scratch. I then found out that apparently
AM1 trips over the density fitting. Next, when removing all instances of
it, I encountered the KEEPCORE error when surf gets to the LMP2 part of
the 2D coupling potential:
ERROR IN CCREST_LOC: INCONSISTENT VALUES FOR KEEPCORE: 0 1
Note that KEEPCORE=1 is required in gradient calculations
As a shot in the dark, I specified "keepcore=1" in the LMP2 input, which
produced some new error ("inconsistent values for NTG"). That's when I
gave up.
Even if the parameter inconsistencies can be resolved (which would be
great for reusing wfu files as I originally intended), I wonder if it
really is not possible to do the AM1 part with density-fitted methods. A
few days ago I was able to calculate a surface on the
1D:DFLMP2/2D:DFLMP2/3D:DFHF levels, the problems only came when I tried
to introduce the AM1 repar ansatz.
Can you reproduce these problems with the input given below?
Another question: What exactly happens if the 1D fits "cause problems",
and what should I do in that case? Try different normal modes?
Best
Matthias
***,surface debug
memory,100,m
file,2,surfdebug.wfu
basis=cc-pvdz
orient,mass
symmetry,nosym
geomtyp=xyz
angstrom
geometry={
6
DF-LCCSD(T)/CC-PVDZ ENERGY=-115.41867456
C 0.0122824456 0.0000000519 -0.7255875507
O -0.0642025366 0.0000000099 0.6927452818
H 0.5252225211 -0.9006938763 -1.1296334856
H 0.5252183133 0.9006956271 -1.1296343846
H -1.0242965819 -0.0000026785 -1.1093361133
H 0.8466037386 0.0000001527 1.0187847588
}
{df-hf
start,atden
accu,16}
{df-lccsd(t),basis=cc-pvdz
local,loc_method=pipek,npasel=0.03
pipek,delete=2}
optg
frequencies
{df-lccsd(t),basis=cc-pvdz,save=1891.2
local,loc_method=pipek,npasel=0.03
pipek,delete=2}
!**Start of SURF calculation**
Label1
abinitio
basis=vdz
int
{df-hf
start,atden
accu,16}
{df-lccsd(t),basis=cc-pvdz,start=1891.2
local,loc_method=pipek,npasel=0.03
pipek,delete=2}
goto,Label4
!*****
Label2
int
{df-hf,basis=cc-pvtz
start,atden
accu,16}
{df-lmp2,basis=cc-pvtz
local,loc_method=pipek,npasel=0.03
pipek,delete=2}
goto,Label4
!*****
Label3
semi,am1
int
rhf
!*****
Label4
{surf,start1d=Label1,dellog=1
vmult,start2d=Label2,start3d=Label3,var2d=emp2,multi=4
repar,type=1
disk,save=5600.2,where=home,dump='surfdebug.pot'}
Am 16-04-2014 17:02, schrieb Guntram Rauhut:
> Hi Matthias,
>
> yes, your label2 construction is exactly, what you would need to do. The
> INT card initializes some variables and recomputes the integrals. In
> principle it should not be needed, but we found it to be important, when
> semiempirical and ab initio calculation will be mixed. Concerning the
> keepcore stuff: As the default parameters in energy single point
> calculations are different from those in geometry optimizations it is
> always advantageous to separate geometry optimization from surf
> calculations once local correlation methods are used. This minimizes
> problems.
>
> Best,
>
> Guntram
>
>
> On 04/16/2014 04:04 PM, Matthias Heger wrote:
>> Hi Guntram,
>>
>> many thanks for your detailed reply. Concerning the Multi scheme I
>> have to admit I found the manual a bit confusing, chances are that
>> some of the fragments I copied were taken from different examples.
>> Judging by your comment I guess this is what I would need to add?
>>
>> Label2
>> {df-hf,...}
>> {df-lmp2,...}
>> goto,Label4
>>
>> and
>>
>> {surf,start1d=Label1,dellog=1
>> vmult,start2d=Label2,start3d=Label3,var2d=emp2,multi=4
>> (...) }
>>
>> Concerning the reparametrization, you are correct, that was not
>> intended - it appears I lost the "repar" card somewhere during
>> testing. May I ask what exactly is the purpose of calling int explicitly?
>>
>> Best regards
>> Matthias
>>
>>
>> PS: The keepcore error I mentioned in my first mail happened from time
>> to time when picking up calculations from wfu files, maybe for same
>> reason as what Andy pointed out with the replicated inputs. I'll save
>> that issue for later.
>>
>>
>> Am 16-04-2014 14:00, schrieb Guntram Rauhut:
>>> Hi Matthias and Andy,
>>>
>>> I had also a look at the input and besides the solution pointed out by
>>> Andy I discovered several problems in the input.
>>> 1) In order to generate smooth potentials one should freeze the orbitals
>>> domains used in the LCCSD(T) calculations. For
>>> doing so I recommend to perform a single LCCSD(T) after the FREQ
>>> calculation, which saves the domains. Within the SURF
>>> calculation, the domains will be read in from the specified record (see
>>> the input below).
>>> 2) Once semiempirical methods are used one needs to take care of the
>>> basis set. As AM1 has a build-in basis set, specifying
>>> a vdz basis for AM1 may lead to trouble. Besides that, the INT card
>>> should be provided prior to the HF calculation.
>>> 3) The MULTI scheme used in the input is disturbing. Presently, LCCSD(T)
>>> calculations will be performed for the 2D terms, but
>>> MP2 energies will be used. This leads to a tremendous computational
>>> overhead. In others word, an explicit MP2 card is missing
>>> for the 2D terms.
>>> 4) The input provided computed the 3D terms at the AM1 level, but will
>>> NOT perform a reparametrization. Is this, what is supposed
>>> to be done?
>>>
>>> Best wishes,
>>>
>>> Guntram
>>>
>>>
>>>
>>> ***,surface debug
>>> memory,100,m
>>> !file,2,surfdebug.wfu
>>>
>>> basis=cc-pvdz
>>>
>>> orient,mass
>>> symmetry,nosym
>>> geomtyp=xyz
>>> angstrom
>>> geometry={
>>> 6
>>> DF-LCCSD(T)/CC-PVDZ ENERGY=-115.41867456
>>> C 0.0122824456 0.0000000519 -0.7255875507
>>> O -0.0642025366 0.0000000099 0.6927452818
>>> H 0.5252225211 -0.9006938763 -1.1296334856
>>> H 0.5252183133 0.9006956271 -1.1296343846
>>> H -1.0242965819 -0.0000026785 -1.1093361133
>>> H 0.8466037386 0.0000001527 1.0187847588
>>> }
>>>
>>> {df-hf
>>> start,atden
>>> accu,16}
>>>
>>> {df-lccsd(t),basis=cc-pvdz
>>> local,loc_method=pipek,npasel=0.03
>>> pipek,delete=2}
>>> optg
>>> frequencies
>>>
>>> {df-lccsd(t),basis=cc-pvdz,save=1891.2
>>> local,loc_method=pipek,npasel=0.03
>>> pipek,delete=2}
>>>
>>> !**Start of SURF calculation**
>>>
>>> Label1
>>>
>>> abinitio
>>> basis=vdz
>>> int
>>> {df-hf
>>> start,atden
>>> accu,16}
>>>
>>> {df-lccsd(t),basis=cc-pvdz,start=1891.2
>>> local,loc_method=pipek,npasel=0.03
>>> pipek,delete=2}
>>>
>>> goto,Label4
>>>
>>> Label3
>>>
>>> semi,am1
>>> int
>>> rhf
>>>
>>> Label4
>>>
>>> {surf,start1d=Label1,dellog=1
>>> vmult,start2d=Label1,start3d=Label3,var2d=emp2,multi=4
>>> disk,save=5600.2,where=home,dump='surfdebug.pot'}
>>>
>>> On 04/16/2014 09:56 AM, Andy May wrote:
>>>> Matthias,
>>>>
>>>> I tried and reproduced the record 1650 problem. However, this only
>>>> occurs because in your restart input you've respecified the geometry,
>>>> basis etc. For whatever reason this causes the conflict, if you
>>>> instead just rely on all of the information saved in file 2, i.e. an
>>>> input as below, then you will not see the problem (you will hit a out
>>>> of memory error, but it's pretty clear what to do there).
>>>>
>>>> I didn't see any keepcore messages in any circumstance.
>>>>
>>>> Best wishes,
>>>>
>>>> Andy
>>>>
>>>> ***Start of SURF calculation
>>>> file,2,surfdebug.wfu
>>>>
>>>> Label1
>>>>
>>>> abinitio
>>>>
>>>> {df-hf,basis=cc-pvdz
>>>> start,atden
>>>> accu,16}
>>>>
>>>> {df-lccsd(t),basis=cc-pvdz
>>>> local,loc_method=pipek,npasel=0.03
>>>> pipek,delete=2}
>>>>
>>>> goto,Label4
>>>>
>>>> Label3
>>>>
>>>> semi,am1
>>>>
>>>> {df-hf,basis=cc-pvdz
>>>> start,atden}
>>>>
>>>> Label4
>>>>
>>>> {surf,start1d=Label1,dellog=1
>>>> vmult,start2d=Label1,start3d=Label3,var2d=emp2,multi=4
>>>> disk,save=5600.2,where=home,dump='surfdebug.pot'}
>>>>
>>>> On 15/04/14 16:24, Matthias Heger wrote:
>>>>> Dear Andy, dear Guntram,
>>>>>
>>>>> thank you for your replies. The input is given below, restarting from
>>>>> the wfu file that contains the Hessian from a separate
>>>>> optimization/frequency calculation (that's the part I commented out).
>>>>> After some tests with other methods I think I'm getting that AM1 part
>>>>> wrong somewhere ...
>>>>>
>>>>> Thanks
>>>>> Matthias
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ***,surface debug
>>>>> memory,100,m
>>>>> file,2,surfdebug.wfu
>>>>>
>>>>> basis=cc-pvdz
>>>>>
>>>>> orient,mass
>>>>> symmetry,nosym
>>>>> geomtyp=xyz
>>>>> angstrom
>>>>> geometry={
>>>>> 6
>>>>> DF-LCCSD(T)/CC-PVDZ ENERGY=-115.41867456
>>>>> C 0.0122824456 0.0000000519 -0.7255875507
>>>>> O -0.0642025366 0.0000000099 0.6927452818
>>>>> H 0.5252225211 -0.9006938763 -1.1296334856
>>>>> H 0.5252183133 0.9006956271 -1.1296343846
>>>>> H -1.0242965819 -0.0000026785 -1.1093361133
>>>>> H 0.8466037386 0.0000001527 1.0187847588
>>>>> }
>>>>>
>>>>> !{df-hf,basis=cc-pvdz
>>>>> !start,atden
>>>>> !accu,16}
>>>>>
>>>>> !{df-lccsd(t),basis=cc-pvdz
>>>>> !local,loc_method=pipek,npasel=0.03
>>>>> !pipek,delete=2}
>>>>> !optg
>>>>> !frequencies
>>>>>
>>>>> !**Start of SURF calculation**
>>>>>
>>>>> Label1
>>>>>
>>>>> abinitio
>>>>>
>>>>> {df-hf,basis=cc-pvdz
>>>>> start,atden
>>>>> accu,16}
>>>>>
>>>>> {df-lccsd(t),basis=cc-pvdz
>>>>> local,loc_method=pipek,npasel=0.03
>>>>> pipek,delete=2}
>>>>>
>>>>> goto,Label4
>>>>>
>>>>> Label3
>>>>>
>>>>> semi,am1
>>>>>
>>>>> {df-hf,basis=cc-pvdz
>>>>> start,atden}
>>>>>
>>>>> Label4
>>>>>
>>>>> {surf,start1d=Label1,dellog=1
>>>>> vmult,start2d=Label1,start3d=Label3,var2d=emp2,multi=4
>>>>> disk,save=5600.2,where=home,dump='surfdebug.pot'}
>>>>> ---
>>>>>
>>>>>
>>>>>
>>>>> Am 14-04-2014 15:59, schrieb Guntram Rauhut:
>>>>>> Hi,
>>>>>>
>>>>>> I would need an input to reproduce these problems and to see if our
>>>>>> solutions work also for this case.
>>>>>> Best,
>>>>>>
>>>>>> Guntram Rauhut
>>>>>>
>>>>>>
>>>>>> Am 13.04.2014 um 18:17 schrieb Matthias Heger:
>>>>>>
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> I am having lots of troubles with surface calculations in Molpro
>>>>>>> 2012.1.
>>>>>>> They frequently crash, telling me that some record 1650 on file 1
>>>>>>> was
>>>>>>> not found. So far I have only been able to resurrect the
>>>>>>> calculations by
>>>>>>> deleting their wfu file and using an old one from previous
>>>>>>> non-surface
>>>>>>> calculations, but even then they still crash again after a while. I
>>>>>>> have
>>>>>>> yet not been able to get past the 1D part of my surface.
>>>>>>>
>>>>>>> Maybe somewhat relatedly, I often encounter an error of inconsistent
>>>>>>> KEEPCORE variables when restarting LCCSD(T) calculations from a wfu
>>>>>>> file. What does this mean, and how do I prevent it? The manual says
>>>>>>> nothing about "keepcore" at all ...
>>>>>>>
>>>>>>> Best regards
>>>>>>> MH
>>>>>>> _______________________________________________
>>>>>>> Molpro-user mailing list
>>>>>>> Molpro-user at molpro.net
>>>>>>> http://www.molpro.net/mailman/listinfo/molpro-user
>>>>>>
>>>>> _______________________________________________
>>>>> Molpro-user mailing list
>>>>> Molpro-user at molpro.net
>>>>> http://www.molpro.net/mailman/listinfo/molpro-user
>>>> _______________________________________________
>>>> Molpro-user mailing list
>>>> Molpro-user at molpro.net
>>>> http://www.molpro.net/mailman/listinfo/molpro-user
>>>
>
More information about the Molpro-user
mailing list