Dear experts,
I was trying to optimize numerically the CH4 geomertry at the MP2 level with fresh Dalton2016. However, the "Numerical derivatives" modules fails due to symmetry transformations of the molecule.
See the readme.rst file in the attached tar file. Even restricting the mol file to the Cs symmetry gives the same error "You may have entered wrong group information."
Any help, please ?
Miro
Numerical geometry optimization with symmetry detection

 Posts: 5
 Joined: 04 Mar 2016, 22:50
 First name(s): Miroslav
 Last name(s): Iliaš
 Affiliation: Matej Bel University
 Country: Slovakia
Numerical geometry optimization with symmetry detection
 Attachments

 ch4_geopt.tar
 see the readme.rst summary line
 (1.1 KiB) Downloaded 400 times

 Posts: 269
 Joined: 27 Aug 2013, 16:42
 First name(s): Kenneth
 Last name(s): Ruud
 Affiliation: UiT The Arctic University of Norway
 Country: Norway
Re: Numerical geometry optimization with symmetry detection
Dear Miro,
It would have been good if you could also have provided the output file, as I am not going to try to rerun these. As such, my answer may be off the point, but I will try to guess:
When running numerical derivatives with the *OPTIMIZE module, I really think you can only run this without symmetry at all (NoSymmetry), the program will not be able to convert for individual displaced geometries in different symmetries between the different symmetry coordinates.
If you want to enforce the symmetry of the molecule, and I would suggest you look at the opportunities offered by the *NMDDRV module. Here you can specify the overall symmetry molecule of the molecule, so that only symmetryunique displacements will be made. Please consult the manual for additional information.
As stated, without the outputs I am guessing a bit, but I nevertheless hope this will be of some help.
Best regards,
Kenneth
It would have been good if you could also have provided the output file, as I am not going to try to rerun these. As such, my answer may be off the point, but I will try to guess:
When running numerical derivatives with the *OPTIMIZE module, I really think you can only run this without symmetry at all (NoSymmetry), the program will not be able to convert for individual displaced geometries in different symmetries between the different symmetry coordinates.
If you want to enforce the symmetry of the molecule, and I would suggest you look at the opportunities offered by the *NMDDRV module. Here you can specify the overall symmetry molecule of the molecule, so that only symmetryunique displacements will be made. Please consult the manual for additional information.
As stated, without the outputs I am guessing a bit, but I nevertheless hope this will be of some help.
Best regards,
Kenneth

 Posts: 597
 Joined: 15 Oct 2013, 05:37
 First name(s): Peter
 Middle name(s): Robert
 Last name(s): Taylor
 Affiliation: Tianjin University
 Country: China
Re: Numerical geometry optimization with symmetry detection
This is not a bug.
As Kenneth says it is not possible to proceed in this way with numerical differentiation. The program is not set up to ensure that the appropriate symmetry can be enforced during such a procedure. This is not to say that it might not work in some situations, but more by luck than by construction. If you wish to use numerical differentiation with .OPTIMIZE you will have to disable symmetry detection ("Nosymmetry"). You can try *NMDDRV but it would appear to be overkill for this particular case: CH_{4} is clearly a onedimensional optimization problem and by running a few energies for different CH bondlengths you can easily locate the minimum by hand.
If you are ultimately interested in more complicated systems and CH_{4} is a simple test then it will be worth exploring more elaborate tactics, like *NMDDRV. By the way, if you are interested in CH_{4} for itself, be aware that at the MP2 level there is an extreme dependence on the basis set and very large sets are needed to see convergence in the bondlength. I can give you references if you are interested.
Best regards
Pete
As Kenneth says it is not possible to proceed in this way with numerical differentiation. The program is not set up to ensure that the appropriate symmetry can be enforced during such a procedure. This is not to say that it might not work in some situations, but more by luck than by construction. If you wish to use numerical differentiation with .OPTIMIZE you will have to disable symmetry detection ("Nosymmetry"). You can try *NMDDRV but it would appear to be overkill for this particular case: CH_{4} is clearly a onedimensional optimization problem and by running a few energies for different CH bondlengths you can easily locate the minimum by hand.
If you are ultimately interested in more complicated systems and CH_{4} is a simple test then it will be worth exploring more elaborate tactics, like *NMDDRV. By the way, if you are interested in CH_{4} for itself, be aware that at the MP2 level there is an extreme dependence on the basis set and very large sets are needed to see convergence in the bondlength. I can give you references if you are interested.
Best regards
Pete

 Posts: 5
 Joined: 04 Mar 2016, 22:50
 First name(s): Miroslav
 Last name(s): Iliaš
 Affiliation: Matej Bel University
 Country: Slovakia
Re: Numerical geometry optimization with symmetry detection
Greetings, Kenneth and Peter (Pete),
thanks for your kind replies. I choose the CH4 as the toy molecule to check the numerical optimization procedure of Dalton (and compare it with DIRAC).
Few observations.
i) The "NoSymmetry" basis, CH4.sto2g.nosymm.mol,
and the "no symmetry breaking" numerical optimization input, geoopt_keepsym.mp2.dal ,
gives error, as the numerical derivatives module calls (by default?) the symmetry detection (finds C2v) and ignores the previous C1 symmetry, or "no symmety".
ii) I choose the MP2 wavefunctions as quick method with the numerical gradient only. Isn't there a .NUMGRA option (like in DIRAC), to force numerical optimization ?
iii) The dalton input with **NMDDRV directives, geoopt_keepsym_numder_C1.mp2.dal ,
together with the CH4.sto2g.nosymm.mol file gives error  again (see the attachement) the SYMADD is beeing called by the NMDDRV module. Isn't this a bug ?
thanks for your kind replies. I choose the CH4 as the toy molecule to check the numerical optimization procedure of Dalton (and compare it with DIRAC).
Few observations.
i) The "NoSymmetry" basis, CH4.sto2g.nosymm.mol,
Code: Select all
BASIS
STO2G
CH4,d(CH)=1.091A,angle(HCH)=109.471 deg

AtomTypes=2 NoSymmetry Angstrom
Charge=6.0 Atoms=1
C 0.000 0.000 0.000
Charge=1.0 Atoms=4
H .629889144 .629889144 .629889144
H .629889144 .629889144 .629889144
H .629889144 .629889144 .629889144
H .629889144 .629889144 .629889144
Code: Select all
**DALTON INPUT
.OPTIMIZE
*OPTIMIZE
.1STORD
# don't break symmetry
.NOBREA
.PRINT
3
**WAVE FUNCTIONS
.HF
.MP2
**END OF DALTON INPUT
ii) I choose the MP2 wavefunctions as quick method with the numerical gradient only. Isn't there a .NUMGRA option (like in DIRAC), to force numerical optimization ?
iii) The dalton input with **NMDDRV directives, geoopt_keepsym_numder_C1.mp2.dal ,
Code: Select all
**DALTON INPUT
.OPTIMIZE
*OPTIMIZE
.1STORD
# don't break symmetry
.NOBREA
.PRINT
3
**NMDDRV
.PRINT
1
.SYMMET
C1
**WAVE FUNCTIONS
.HF
.MP2
**END OF DALTON INPUT
 Attachments

 geoopt_keepsym_numder_C1.mp2_CH4.sto2g.nosymm.out
 (36.04 KiB) Downloaded 372 times

 Posts: 87
 Joined: 06 Sep 2013, 13:49
 First name(s): Sonia
 Last name(s): Coriani
 Affiliation: DTU Chemistry
 Country: Denmark
Re: Numerical geometry optimization with symmetry detection
Dear Miro,
if your target is the optimized MP2 geometry, you can run it analytically via
the coupled cluster module.
Best regards
Sonia
if your target is the optimized MP2 geometry, you can run it analytically via
the coupled cluster module.
Best regards
Sonia

 Posts: 597
 Joined: 15 Oct 2013, 05:37
 First name(s): Peter
 Middle name(s): Robert
 Last name(s): Taylor
 Affiliation: Tianjin University
 Country: China
Re: Numerical geometry optimization with symmetry detection
The original posting ran a vague bell and thinking that I had had a calculation like this work I asserted this wasn't a bug. While I withdraw that assertion I am not convinced that the calling SYMADD itself is the cause. Because I went back to my own calculation, which turned out to be related to a problem someone was having calculating second derivatives by numerical differentiation to get vibrationally averaged spinspin coupling constants for cyclobutane (at a D_{2d}symmetry geometry). I used the following input for this
where the input under **NMDDRV calls for second derivatives to be calculated as first numerical differences of analytical gradients. This calculation runs to completion.
Nevertheless, at every displaced geometry (the .SYMMET option notwithstanding) it calls SYMADD and very often discovers higher than C_{1} symmetry (sometimes even D_{2d} itself) but it never uses other than C_{1} symmetry for any of the displaced geometries.
So I do not think the problem is necessarily with the numerical differentiation part of the calculation in your case. But you are of course doing something quite different (numerical first derivatives as part of a geometry walk with .OPTIMIZE). And it appears at subsequent geometry steps the program, when it reads the MOLECULE.INP file to obtain the next geometry step to calculate the integrals, does discover and use the symmetry even though the original .mol file had "Nosymmetry" specified. This almost certainly is a bug, but I strongly suspect it is a bug in how the geometry optimization routines generate the input file for the next step, not something that results from checking the symmetry in the numerical differentiation routines. I say this because in my own example, which involves no geometry optimization of course, the code discovers higher symmetry but uses C_{1} throughout.
Specifying the .NOBREA option has no effect on firstorder optimizations like yours, by the way  it is possible only for secondorder methods.
All this said, a way forward for you may be to use the CC code. It can do numerical differentiation, and it can do MP2 as well as, or instead of, CC methods. CC gradients are available too, but I am not sure this is the case for MP2, although I believe it is for the closely related CC2. This is all documented in the manual. What the situation is with generating new geometry steps and testing for symmetry I don't know because I've never used this functionality. But until something is done about ensuring that "Nosymmetry" is propagated correctly through geometry optimizations using numerical differentiation to get the gradient it might be an alternative. The CC code is not parallelized (although it can be run integraldirect) but I am not sure whether there is any benefit running parallel for MP2 with SIRIUS anyway.
Best regards
Pete
Code: Select all
**DALTON INPUT
.PARALLEL
.NMDDRV
**NMDDRV
.VIBANA
.DISPLA
0.01
.SYMMETRY
C1
.DORDR
1 1
*PROPAV
.ANHAP
**WAVE FUNCTIONS
.DFT
B3LYP
*SCF INPUT
.THRESH
1.0D6
**EACH STEP
.SPINSPIN
*SPINS
.SELECT
3
1 2 3
*TRPRSP
.THRESH
1.0D6
*LINRES
.THRESH
1.0D6
*END OF INPUT
Nevertheless, at every displaced geometry (the .SYMMET option notwithstanding) it calls SYMADD and very often discovers higher than C_{1} symmetry (sometimes even D_{2d} itself) but it never uses other than C_{1} symmetry for any of the displaced geometries.
So I do not think the problem is necessarily with the numerical differentiation part of the calculation in your case. But you are of course doing something quite different (numerical first derivatives as part of a geometry walk with .OPTIMIZE). And it appears at subsequent geometry steps the program, when it reads the MOLECULE.INP file to obtain the next geometry step to calculate the integrals, does discover and use the symmetry even though the original .mol file had "Nosymmetry" specified. This almost certainly is a bug, but I strongly suspect it is a bug in how the geometry optimization routines generate the input file for the next step, not something that results from checking the symmetry in the numerical differentiation routines. I say this because in my own example, which involves no geometry optimization of course, the code discovers higher symmetry but uses C_{1} throughout.
Specifying the .NOBREA option has no effect on firstorder optimizations like yours, by the way  it is possible only for secondorder methods.
All this said, a way forward for you may be to use the CC code. It can do numerical differentiation, and it can do MP2 as well as, or instead of, CC methods. CC gradients are available too, but I am not sure this is the case for MP2, although I believe it is for the closely related CC2. This is all documented in the manual. What the situation is with generating new geometry steps and testing for symmetry I don't know because I've never used this functionality. But until something is done about ensuring that "Nosymmetry" is propagated correctly through geometry optimizations using numerical differentiation to get the gradient it might be an alternative. The CC code is not parallelized (although it can be run integraldirect) but I am not sure whether there is any benefit running parallel for MP2 with SIRIUS anyway.
Best regards
Pete

 Posts: 597
 Joined: 15 Oct 2013, 05:37
 First name(s): Peter
 Middle name(s): Robert
 Last name(s): Taylor
 Affiliation: Tianjin University
 Country: China
Re: Numerical geometry optimization with symmetry detection
I had not noticed Sonia's posting until after I submitted mine: clearly you can do what you want with the CC code if that makes sense for your "real" molecule too.
Best regards
Pete
Best regards
Pete
Who is online
Users browsing this forum: No registered users and 1 guest