CM5 charges differ from LigParGen implementation - ORCA?

[mattiafelice-palermo]

Hello Selim,

I hope everything's well.

I have stumbled upon the implementation of CM5 charges calculation in LigPargen (https://github.com/leelasd/ligpargen/blob/master/Orca2CM5charges.py), which comes as an executable script that can be easily run on the ORCA output file.

I have noticed that the charges from Q-Force CM5 implementation differ substantially from the ones returned by the script of Dodda. For example, I was looking at isosorbide dimethyl ether, and these are the charges from Q-Force and CM5 script (both already rescaled by 1.2):

Of course I can provide all input files if needed. But maybe you might have an idea of why this is happening. Maybe Q-Force is averaging the charges over multiple geometries (I did not get the change to go through the code section for the charges calculation)? For the CM5 script, I just used the ground state geometry.

Thank you for your input!

[selimsami]

Hi Mattia,

Which QM method have you used in both cases?

Also which QM software have you used? Q-Force simply gets the CM5 charges from the QM output for Q-Chem and Gaussian. However, it prints Hirshfeld charges for ORCA since it does not have CM5. The code you shared can be useful for converting ORCA's Hirshfeld into CM5

[mattiafelice-palermo]

Hello Selim,

thanks for the feedback! I gave a look at the code. Indeed, as you said, in orca.py only the Hirshfeld charges are taken without doing any additional processing for converting them to CM5.

Maybe this could be to mentioned in the documentation for the Orca software section, or appear as a warning in Q-Force output - that the user is responsible for converting themselves? As one would assume that using CM5 would indeed return CM5 and not Hirshfeld.

Anyway this solves it on my side, thanks!

P.s.: I've modified the issue title so that it's clear this only affects ORCA

[selimsami]

Thanks Mattia, I updated in my working version for qforce 2.0 cm5 in orca to hirshfeld so there are no confusions.

Would be really useful to incorporate that script to Q-Force. Only thing I don't like is the rdkit dependence. I'll leave this issue opened in case someone has the time/interest to adjust that script into qforce without the rdkit dependence. It doesn't look very complicated.

[mattiafelice-palermo]

Great, thank you for taking this into consideration!

I think the rdkit dependency is only for the symmetrization of the charges based on FPS. But I think in Q-Force you already have a symmetrization algorithm which could be applied to the calculated charges.

What is your tentative timeline for Q-Force 2.0? I could work on implementing this, but my schedule is a bit tight at the moment, so I would need to organize accordingly.

[selimsami]

Indeed Q-Force takes care of the symmetrization so we dont need that, that's great!

Planning to finish everything by the end of August latest. I think you could work on this on your own timeline since it is more or less decoupled from the rest of the things we are working on. It's basically a separate function that reads Hirshfeld charges and returns CM5 charges without other dependencies as far as I understood?