New property? optstate?

[oliver-s-lee]

Hi folks, long-term fan of the project.

I'd like to suggest a possible new parsed property that would be useful for optimised excited states calculations. In such calculations, it is often useful/necessary to calculate more than one excited state at each geometry step. For example, to optimise the second singlet excited state, it is necessary to calculate at least the first two singlet states (and often more would be requested). This is fine, but can make it unclear which excited state geometry is actually being optimised, and as far as I know this information is not available in the current cclib parsed data.

To address this, I would suggest a new property, called something like 'optstate', which would contain the index of the state being optimised (in the same manner as 'homos'). For Gaussian at least, this should be easy to implement, as the relevant state is marked explicitly by This state for optimization and/or second-order correction. (the first state in the below example):

...
Excited State   1:      Triplet-A      4.2757 eV  289.98 nm  f=0.0000  <S**2>=2.000
      21 -> 22         0.69591
      21 -> 26         0.10972
 This state for optimization and/or second-order correction.
 Total Energy, E(CIS/TDA) =  -247.849832098    
 Copying the excited state density for this state as the 1-particle RhoCI density.
 
 Excited State   2:      Triplet-A      4.2914 eV  288.91 nm  f=0.0000  <S**2>=2.000
      17 -> 26         0.10009
      19 -> 22        -0.38874
      20 -> 23         0.57871
...

If this sounds useful I can have a go implementing for the Gaussian parser?

[berquist]

This is partially specified in the input, which we tend to put in metadata for now. But if the program does some sort of state following, where the target state to take the derivative of can change, then it's more in line with a full-on attribute. I'm not sure how common this is, though, compared to just picking which state to take the gradient of. What do you think?

[amandadumi]

For the cases I've run into related to this, I've used this as a reference index. It would be nice information to have and metadata feels appropriate.

[oliver-s-lee]

My initial feeling was that because this property effects the interpretation of other derived properties it perhaps felt better as its own attribute. For example, if one was interested in calculating the relaxed emission energy of a system, then roughly that could be obtained by (with appropriate unit conversions):

vertical = excited.etenergies[excited.optstate]

Or for adiabatic emission which would normally require a separate ground state calculation too:

adiabatic = ( excited.scfenergies[-1] + excited.etenergies[excited.optstate] ) - ( ground.scfenergies[-1] )

As far as I know, no other metadata item is used to interpret other properties in this way? Regardless it seems like this would be useful so I'll start on an implementation. Where the data actually ends up isn't too important I guess and it's always easy to change.

[shivupa]

Closed via #1151