There is quite a few problems with how transition calculations are done in GAMESS, and I essentially want to raise awareness of them and potentially provide some fixes for some of them.
I am supplying some personal modified source files that are relevant to these issues. Each change should be marked with
C ZS:
and a comment explaining the change if I felt it was important, some changes for pure printout reasons may not be commented.
Essentially, there were structural changes to how symmetries were treated inside these calculations, that breaks or limits functionality that were once usable. I imagine these changes occurred around when GAMESS implemented the ability to but symmetry info into inputs, instead of requiring one to reference an external document. (So, quite a long time ago.)
As I'll include commented code with string tags, I'll just put a potential problem list here for readability, but relevant areas of the source code should be tagged, commented, and maybe even fixed, though in a probably less than ideal way.
Inside of trnstn.src
There is an undocumented change to the TOLE functionality of $TRANST inside the code. Negative TOLE values read in all of the supplied vector group, which helps with supplying clean virtual frozen MOs for CI calculations. This shouldn't really be necessary, but it is, for reasons I'll get into later. I agree with making this functionality available, but I believe there was a small mistake in its implementation. It seems to be using the reference value for number of AOs instead of MOs. This breaks it when using spherical harmonics or when linearly dependent MOs are dropped. However, this removes problems from constantly regenerated new virtual orbitals, and should be in the documentation.
When doing a nonrelativistic dipole moment calculation, the results of each DRT group calculated are overwritten by the next. Then, after all calculations are done, it complains and quits. This completely removes the ability to use seperate DRTs for different symmetry groups of the same multiplicity, needlessly increasing computational effort and removing functionality. This doesn't happen with relativistic calculations, which means a fix to this should actually be quite easy, and would make using multiple DRTs possible again, regaining functionality that was lost at some point in the past. (TLDR; it is impossible to calculate the subgroups of spatial symmetry separately in a dipole moment calculation. It wasn't always that way. The fix should be easy.)
There is a call to TRFMCX() on every DRT run. As is, this function will reorthogonalize your MOs. Doing this successively for many MOs seems to eventually break symmetry, and at best, slightly changes your MO vectors between each DRT calculation. This orthogonalization is actually already done once, in TRANSINI(), so it should be avoided here, though maybe explicit purification arguments should be added to the TRANSINI function and made available on input? Left as is, this pretty much removes the ability to utilize symmetry for larger systems in transition calculations. (I understand that this may have done because of the ability to use different sized active spaces, but there has to be a more stable way. At the very least, one should probably not be relying on the orthogonal generation of a virtual space in anyway for transition calculations anyway.)
Inside of trans.src
I have piggybacked on someone else's code inside of TRFMCX to avoid the purification and orthogonalization. The fix is easy.
Inside of gugdrt.src
There is an if conditional dependent on symmetry arguements. Inside this if conditional, there are adjustments made for if a transition type calculation is occurring. I have never once been able to enter this if block in a transition calculation, as the conditions cause errors elsewhere. The else block for this does not have the necessary adjustments made for transition calculations, causing issues.
Other than that, it might be nice to add functionality which lets users see the IORDER array, which is an array that gives the order of MOs as they are referenced in case vectors.
Sorry for the long post, but this has been an issue that has bugged me for a long time.
[x] Summary of the issue and expected results.
[x] Description of the run environment: (Through install.info)
install.txt
There is quite a few problems with how transition calculations are done in GAMESS, and I essentially want to raise awareness of them and potentially provide some fixes for some of them.
I am supplying some personal modified source files that are relevant to these issues. Each change should be marked with C ZS: and a comment explaining the change if I felt it was important, some changes for pure printout reasons may not be commented.
Essentially, there were structural changes to how symmetries were treated inside these calculations, that breaks or limits functionality that were once usable. I imagine these changes occurred around when GAMESS implemented the ability to but symmetry info into inputs, instead of requiring one to reference an external document. (So, quite a long time ago.)
As I'll include commented code with string tags, I'll just put a potential problem list here for readability, but relevant areas of the source code should be tagged, commented, and maybe even fixed, though in a probably less than ideal way.
Inside of trnstn.src
Inside of trans.src
Inside of gugdrt.src
trans.txt trnstn.txt gugdrt.txt
Other than that, it might be nice to add functionality which lets users see the IORDER array, which is an array that gives the order of MOs as they are referenced in case vectors.
Sorry for the long post, but this has been an issue that has bugged me for a long time.