Add an option to loosen the criteria for symmetry from GAMESS input file #52
Comments
shoubhikraj
changed the title
|
I am not a GAMESS-US developer; however, if there is a problem here, it is with wxMacMolPlt, not GAMESS. In the nutshell: in ferrocene, the carbon and hydrogen atoms fall exactly on the symmetry planes, so that these sites have non-unit multiplicity. The input file produced by wxMacMolPlt does not generate these positions with a sufficiently high accuracy, so that GAMESS (correctly) treats them as general points. Basically, you want GAMESS to recognize approximate symmetries, and to symmetrize the user-supplied data to match what the user intended, rather than that the user specified. That is a very, very long and slippery slope. If one gives more significant digits on input: $CONTRL SCFTYP=RHF RUNTYP=ENERGY MULT=1 COORD=UNIQUE $END $SYSTEM TIMLIM=525600 MEMORY=1000000 $END $BASIS GBASIS=MINI $END $SCF DIRSCF=.TRUE. $END $DATA Title DND 5 C 6.0 0.70621253168819 0.972018160625 -1.79688 H 1.0 1.33771006712866 1.841199951228 -1.85824 Fe 26.0 -0.00000 0.00000 0.00000 $END your example runs just fine. Alternatively, if one places the generating atoms at a position where sigma-d planes coincide with the Cartesian planes, one can user fewer significant digits: $CONTRL SCFTYP=RHF RUNTYP=ENERGY MULT=1 COORD=UNIQUE $END $SYSTEM TIMLIM=525600 MEMORY=1000000 $END $BASIS GBASIS=MINI $END $SCF DIRSCF=.TRUE. $END $DATA Title DND 5 C 6.0 0.0 1.2014805218978 -1.79688 H 1.0 0.0 2.2758482998873 -1.85824 Fe 26.0 -0.00000 0.00000 0.00000 $END If it is any consolation, generating high-symmetry inputs with atoms occupying high-multiplicity positions is a hard problem - regardless of whether one does it by hand or with the aid of a GUI. |
|
Thanks for the reply. May I ask which program you used to generate the symmetrized coordinates with higher number of significant figures? I understand that the problem is due to MacMolPlt not writing the coordinates with a high enough precision. I tried the WebMO symmetrizer and I still ran into the same problem. If the common GUI editors cannot write coordinates with that high number of decimal places, then what is the point of GAMESS enforcing such a strict criteria? I had also posted the problem on the repository for wxMacMolPlt here. But I think GAMESS should have an option to change the threshold for symmetry detection from the input file. It is not a slippery slope at all because most other QM codes including Orca, Gaussian, NWChem have an option to change the tolerance. GAMESS is the only program I have come across so far that doesn't. (I suspect the option is there inside the GAMESS code, it's just not modifiable from the input) |
I used a calculator and a piece of paper. The X/Y ratio in your input should have been equal to the tangent of 36 degrees. As far as implementing the feature you requested, only the GAMESS developers can give you a definite answer. However, please consider the following: Let's assume the feature you want has been implemented (which would be rather easy to do: as far as I can see, all one has to do is to make the constant 2394 IF ((QMCHKA.EQV.QMCHKB).AND.(TEST.LE.1.0D-12)) THEN 2395 GO TO 820 2396 END IF 2397 ELSE 2398 IF(TEST .LE. 1.0D-12) GO TO 820 2399 END IF What happens now? All you have done is to force GAMESS to treat a broken-symmetry Hamiltonian as if it was actually symmetric. At best, this will cause mis-classification of orbital- and state-symmetry labels. At worst, it will make calculations which do rely on the Hamiltonian symmetry (e.g. finite-difference Hessian calculation) produce wrong results. Therefore, by itself, this is not a particularly attractive solution. The obvious way to make it somewhat sensible would be to notice that the symmetry is (slightly) broken, and automatically set Another approach would be to recognize that the molecule is approximately-symmetric, and forcibly symmetrize it (as far as I remember, this was the approach taken by Gaussian some 20 years ago, when I last used it). This will necessarily cause a change in the molecular geometry and/or orientation relative to that was specified on input. This may be OK in some cases, but in the others. Given that there is no obviously "correct" way of handling this situation, I would rather have the code detect an error in my input, and stop - rather than trying to guess what was it I actually wanted. However, this is simply my personal preference. Again, only the GAMESS developers can give you a definite answer. |
Make sure these boxes are checked before submitting your issue - thank you!
I am trying to build an input file for a ferrocene molecule with D5d symmetry. For creating the structure, I started from a structure provided by another software, and then used wxMacMolPlt to detect point group, and then impose D5d point group on the molecule. The input file was generated by wxMacMolPlt.
However, on running the input file with GAMESS, it shows an error because the atoms generated by the symmetry operations are less than 0.1 Angstrom apart, which means that GAMESS is producing extra atoms that are not supposed to be there. The output:
As you can see, GAMESS is producing 20 carbon atoms whereas ferrocene should have 10 carbon atoms. Looking closely at the cartesian coordinates of the atoms generated by the symmetry operations, there are several pairs of atoms which are essentially the same but are treated as different atoms by GAMESS. For example, C1 and C12 are apart by 0.0000063 Angstrom (from the internuclear distance matrix), but they are treated as different atoms. The requirement for this level of precision seems unnecessary, particularly as input builder softwares (like wxMacMolPlt) cannot impose symmetry constraints with that amount of precision.
I have also tried using WebMO to impose symmetry and write input file for GAMESS, but it still runs into the same problem. Therefore, I think there should be an option available through a keyword in the input file, which simply sets the tolerance for identifying unique atoms (by their distance perhaps).
This problem seems to appear more often for point groups with higher symmetry like D5d, D5h, Td etc. than for lower symmetry point groups. It also breaks the usability of the symmetry feature of GAMESS.
The text was updated successfully, but these errors were encountered: