ComputeDipoleMoments._compute_charge_derivatives incorrectly expects OpenMM units from system_subset

[Shahriar-Keshvari]

Hello:

I have followed the tutorial 4 (using ForceBalance) to optimize the Lj parameters. The code runs successfully; however, upon adding the dielectric constant calculation, I get an error:

 "AttributeError: Neither Quantity not it's magnitude (blah) has 'unit'. Did you mean units? " 

This error message seems to be misleading because the magnitude term (blah) is taken from the "vdW" part of the SMIRK input file. I do have the "LibraryCharges" defined.

Again, if I stick with density and Enthalpy of vaporization, the code works fine. The "id" used for each atoms in "LibraryCharges" and "vdW" part are the same and also I am using the same SMIRK to define them. In the working directory, I can see that the production simulation has been completed successfully and the folder for "compute_dipole" is empty.

Please let me know if you need more information or clarificaiton!

Thanks
Shah

[lilyminium]

Thanks for the report, Shah. Is blah from the actual error message or something you added? Either way it sounds like an existing bug we are aware of: #674

This is still to be fixed, but if you set the uncertainty of your property to a dummy value (e.g. 1 * unit.dimensionless) it should avoid triggering the error path.

[Shahriar-Keshvari]

Thanks for pointing the bug out. I did replace the magnitude of the number with the term "blah".

To bypass this error, I should set the uncertainty of the physical property to (1 * unit.dimensionless) where I set the thermodynamic states like below:

DielectricConstant( thermodynamic_state=thermodynamic_state, phase=PropertyPhase.Liquid, substance=PRP, value= 27.7* unit.dimensionless, uncertainty = 1*unit.dimensionless, source=None )

Because I did this and the problem still exist. Am I missing something else?

Now, does the same bug applies to MolarExcessVolume as well?

[lilyminium]

Now, does the same bug applies to MolarExcessVolume as well?

The bug applies across the board unfortunately.

Hmm. Could you please post the full error trace so we can see the line that triggers? The bug in #674 specifically refers to when the uncertainty is UNDEFINED.

[Shahriar-Keshvari]

error.txt

I have uploaded the error file output. This happens only when I include the dielectric constant calculations.

If possible, to share how to fix this problem, that would be great.

Cheers

[lilyminium]

Thanks @Shahriar-Keshvari , that was helpful. In the future could you please just directly paste the message into the GitHub comment to save a file download? That'd be easier for us to parse.

Ok, this looks like a separate bug. I'm 80% sure this is from a mismatch in units. The mismatch is probably coming from this line in system_subset already returning Pint units

openff-evaluator/openff/evaluator/utils/openmm.py

Lines 247 to 248 in 98b50ba

	if not is_quantity:
	parameter_value = parameter_value * unit.dimensionless

while the corresponding code in computing dipole moments below, expects an OpenMM unit:

openff-evaluator/openff/evaluator/protocols/analysis.py

Lines 619 to 620 in 98b50ba

	reverse_value = from_openmm(reverse_value)
	forward_value = from_openmm(forward_value)

I expect the quickest fix would be to switch the second part of the code to the below (or just remove the lines):

 reverse_value = reverse_value
 forward_value = forward_value

@Shahriar-Keshvari you'd be welcome to open a pull request if this fixes your issue, otherwise we will sort this somewhere into our existing list of priorities, where unfortunately it may not be the top. A PR should contain a test that fails before the fix and passes after the fix is applied.

If you’d prefer not to open a PR but can provide a minimal reproducing example that could be easily turned into a test, that would really help us put in a fix. In fact, coming up with a good test case is usually the hardest part of the work here.

[mattwthompson]

I don't have time to dig through this deeply but on a quick reading Lily is quite likely to have found paydirt. We'd be happy to take a PR for this, or a minimally reproducing example would be most of the work

[Shahriar-Keshvari]

Kudos to Lily, commenting the two lines [analysis.py] solved the problem. I will try the "Molar excess volume" and will let you know.

FYI, I took the advice of Jeff to see if this could be solved by updating some packages and by the means of try and error, I could not find any match between any of the updated packages. Essentially, any pint version that is newer than 0.23.0, is not compatible because apparently the "measurement" method has been deprecated and openff need this method.

I can not use python 3.13, for which it appears that it can be the solver (since all packages are compatible) but the issue is that openeye-toolkit can not work with any versions of python newer than 3.12.

Thanks
Shah