Dalton forum

Hi,
I know these are exotic properties but Dalton actually has an own keyword for the calculation of two-photon circular dichroism (.TPCD in the *QUADRA group). Using this keyword I get exactly what I want to calculate TPCD cross sections: Electric dipole-magnetic dipole transition tensors, electric dipole-electric dipole transition tensors and electric dipole-electric quadrupole transition tensors - all expressed in velocity gauge to get origin independent results. This is nice. But what is not so nice however, is that the printing of these results is extremely messy. Per state I need 36 different tensor elements, sometimes I even get 90 when also the DIPLEN operator is involved. It is not impossible to gather these elements from the output using a shell script but it is of course kind of painful as you cannot grep specific elements from the output as the operator labels are never printed in the same line as the tensor elements.

The amount of pain is even increased if the molecules get symmetry. Then the tensors are completely messed up and up to now I did not invest the effort to write a shell script for that. I think this could be way easier with some help from the Dalton developers. There is actually a very compact printing of the two-photon absorption tensor after a TPA calculation. Would it be possible to modify this such that also the other tensors can be printed in this way? To be precise this should be
1.) The electric dipole-electric dipole transition strength tensor in velocity gauge (DIPVEL/DIPVEL different elements per state)
2.) The electric dipole-magnetic dipole transition strength tensor in velocity gauge (DIPVEL/ANGMOM, 9 different elements per state)
3.) The electric dipole-electric quadrupole transition strength tensor in velocity gauge (DIPVEL/ROTSTR, 18 elements per state)

Then the evaluation of the data (which is rather complex for TPCD) would be way easier. Another thing which I would really appreciate for this tensor printing (also for the existing one) would be if we could get some more decimal places in the compact output. Thank you in advance for the effort!

On the one hand I admit to talking out of turn here: I have never run a TPCD calculation (and indeed I'm not sure I've ever run even a one-photon CD calculation!). But it does seem to me that you are saying, basically, "all the information is there, why don't you present it in a more intelligent way?". And my first thought is "if all the information is there and just needs to be presented in a better way, can't you write a few print statements and the associated arithmetic to print what's needed and put it in the code?" After all, you have the source! If indeed your thinking is of general utility this would be very helpful to everyone and would certainly be regarded (I would like to think) as a genuine contribution to the program.

I think "feature suggestions" has tended to be more of people suggesting including e.g. DFT/MRCI than how to format the output for particular tensors. If all of the information for the latter is available (and it seems that it is), reassembling it for display in a different way is not really any of the sort of breaking new ground that constitutes a "new feature", I think. I say this not to discourage people from thinking about improving the program! But a change to the way information is presented in the output, well, I think a code fragment submission accompanied by an "instead of printing all this stuff that nobody can make sense of why not replace it with this code that prints what people do want to see" would get much quicker acceptance from the developers! Especially because they wouldn't have to do any work!!

Best regards
Pete

Hi Pete,

The new feature is already in its testing procedure after a short talk with Kenneth. I have the source code of Dalton but I was not sure whether I was allowed to change anything in it that has not to do with my work (which deals with a Dalton submodule). But having realized that I will not be hanged, drawned and quartered when I implement this, I actually did....

On the other hand, which place is actually appropriate for a user to comment on an output (or input) structure? "Running Dalton", "General discussions"?
I often hear that some parts of output are not very user-friendly or difficult to read and now I will immediately give the link to the proper place!

I didn't want to inhibit postings that might improve the program! But changing/augmenting the way already-calculated quantities are presented is (in my perhaps doctrinaire view) not a new feature. It is not achieving something that the program was not already capable of: it is a presentational change. A new feature would be, say, open-shell CC.

And I have to repeat my earlier comment: if someone can see that simply reassembling the final quantities and printing them differently is the need, isn't the best way to raise this just doing it, and then posting "wouldn't it be better if this was done this way?", which is what the original poster seems to be already doing, based on his last post? And more power to him for doing it!

Best regards
Pete

Peter, I am not arguing with you, I see your point. Yes, printing is not a new feature.
But I still am curious what is the right place a user should do it?
Or e.g. ask for more timing printouts (or how to insert them) or comment about the extensive amount of memory statistics in the output.

Maybe we need a "Tweaks" thread? Or at least something that does not imply new functionality, but rather a restructuring or reformatting of what is already there (or is already input), or what we already implicitly calculate but don't explicitly output.

Best regards
Pete

I do not have very strong opinions on this matter, but I note that the "Feature suggestions" section has 8 entries in more than 1.5 years. Thus, it doesn't appear that it should be a particular need to split the thread into two parts in order to handle the volume of postings. The important part is, perhaps, that small, neat suggestions that are posted and which is fairly easy to implement (by a user skilled in programming herself or by a developer) is picked up and for instance given a ticket, that one or more developers could pick up on a rainy day.....

In terms of larger feature suggestions, my fear would anyway be that it will not be implemented, no matter how good a suggestion it is, unless some developer also needs this functionality. For a code for which all developments are funded by research projects, this is probably inevitable.


Kenneth

hi,
I was surprised to read that you (Daniel) were worried whether such a contribution was welcome.
In my opinion every tested and documented contribution which makes the code
better [*] is welcome - whether the contribution originates
from a core developer or a collaborator or a user or computing center
support staff.
radovan

[*] easier, faster, more accessible, ...