I have read through this code and I have three thoughts:

1. all code that computes attributes based on other attributes (dipole gradients here) should go in the methods part of cclib
2. I don't adding very niche attributes that are not likely to be implemented for other parsers is a good idea
3. despite 2, it would be a waste to throw away good parsing code just because it is very specific, so I am thinking about how to reconcile these two feelings

Re point 1., I had similar thoughts myself. However, the code that calculates numerical Cartesian et transition dipole gradients from a TD/CIS numerical frequency calculation is not easily generalizable, as different codes perform such calcs in different ways. During a Gaussian numerical freq calc, a series of single point calculations are performed over a grid of geometries with positive and negative displacements of each Cartesian degree of freedom, with a constant step size. However, some codes loop over a different grid of displacements, for example to make use of symmetry to reduce the number of calculations required. Also, some codes don't support analytical TD/CIS gradients, so enough information to calculate numerical et transition dipole gradients would be present in a numerical gradient calculation. Hence, I chose to put the method to calculate the et transition dipole gradients in the Gaussian parser..

Re point 2., yes, Herzberg-Teller effects are perhaps a little niche, but this is also subjective. Functionality to simulate Herzberg-Teller effects in absorption/fluorescence was added to Gaussian in 2009 (Rev A02), if that is any measure of general interest. If it makes a difference, perhaps I could create feature requests to add corresponding functionality for other codes, which I or others could get to when time permits.

Another thought - what if I split this up in two pieces 1) parsing transition dipole moments (which is definitely not niche - cclib already parses et oscillator strength and rotary strengths, and this feature could be easily added to all parsers) and 2) calculation of HT gradients (which is more niche, and could just stay on my personal fork for the time being) ?
If this sounds good to you, please let me know and I will proceed in that way.

Yes, that would make things much easier.

I'm still not convinced that the gradient calculations belong in the
parser.

Parsing niche (however understood) attributes is still OK generally I
think, but we need to be diligent about how many new attributes are added.

On Mon, Jan 11, 2016 at 8:23 AM, mwykes [email protected] wrote:

Another thought - what if I split this up in two pieces 1) parsing
transition dipole moments (which is definitely not niche - cclib already
parses et oscillator strength and rotary strengths, and this feature could
be easily added to all parsers) and 2) calculation of HT gradients (which
is more niche, and could just stay on my personal fork for the time being)
?
If this sounds good to you, please let me know and I will proceed in that
way.

—
Reply to this email directly or view it on GitHub
#225 (comment).

So I've just made a pull request #227 containing only the transition dipole parsing functionality (with the dipole gradient-calculating code left out).

Slightly separate from the HT discussion, I think parsing of the step size for numerical differentiation is both general and important. All programs that I know of can (or even have to) do this, and they usually have different defaults.

Slightly separate from the HT discussion, I think parsing of the step size for numerical differentiation is both general and important. All programs that I know of can (or even have to) do this, and they usually have different defaults.

Thanks Eric. Can you pinpoint a good logfile example of where this is printed?

Most codes support analytical frequencies for ground-state DFT calculations such as the dvb_ir unit test, so much more time consuming numerical frequencies are typically reserved for excited states or other methods for which analytical gradients are not available. However, I noticed that for some reason or another, the basicORCA3.0/dvb_ir.out calculation is a numerical frequency calculation (despite that fact that ORCA support analytical gradients for ground-state calculations). The relevant line of that file is:

Numerical increment            ...  0.005 bohr               

Indeed the default in Gaussian differs to the default in Orca.. in Gaussian it is:

Nuclear step= 0.001000 Angstroms

I have a log file for a Gaussian09 TD-DFT numerical freq calculation of dvb - but it's relatively large at 3.9MB. dvb_td_freq.zip

However, I noticed that for some reason or another, the basicORCA3.0/dvb_ir.out calculation is a numerical frequency calculation (despite that fact that ORCA support analytical gradients for ground-state calculations).

This might be because it was only v3.0 that they introduced analytic frequencies, and the input files were probably just copied from v2.9.

Thanks Eric. Can you pinpoint a good logfile example of where this is printed?

We should already have several outputs that contain this information, though; in addition to the ORCA frequency calculation, most calculations of Raman intensities require a numerical differentiation of the polarizability wrt nuclear coordinates:

Firefly/PC-GAMESS and Q-Chem both calculate the electric dipole and nuclear gradient while varying the applied e-field strength numerically. DALTON also takes the numerical nuclear gradient (not sure why).

Output examples are:

DALTON/basicDALTON-2013/dvb_raman.out (not printed if default step size)
DALTON/basicDALTON-2015/dvb_raman.out (not printed if default step size)
GAMESS/basicFirefly8.0/dvb_raman.out (printed)
QChem/basicQChem4.2/dvb_raman.out (printed)
regression/GAMESS/PCGAMESS/dvb_raman.out (printed)

I have a log file for a Gaussian09 TD-DFT numerical freq calculation of dvb - but it's relatively large at 3.9MB.

Taking a look at this:

Nuclear step= 0.001000 Angstroms, electric field step= 0.000333 atomic units

makes me realize that for completeness, there should be 3 attributes:

1. nuclear step size
2. electric field step size
3. magnetic field step size

I've had time to think and my stance is different. The step size is an input parameter, with a default value or otherwise, not an output of the calculation. So I don't think it should be an attribute in cclib - those are normally outputs of the calculation.

So let's talk about parsing input parameters. There have been recurring discussions about it in the past, and in general I think that is a good thing to have but we have never settled on a format/specification. There has never been an overwhelming demand for this, since it doesn't relieve one of the craftsmanship needed when setting up a job. Although it would make it possible to write an input in one program and then read it and write it out for another program, and that is definitely useful in some limited sense. And as in this case, it is useful or even necessary for some downstream calculations. Datawise, I don't know if a dictionary or a new class (ccParams?) is the best way to go.