Use value of target density when preparing liquid simulations from density data?

[mattwthompson]

Start with a narrow problem: given some ThermoML targets¹ for liquid density and want to prepare some associated simulations. Since you know what the density is purported to be via experimental measurements, you can use those values when packing the box. The downside is that when preparing otherwise identical² liquid simulations, these values aren't so accessible. De-duplication of compute jobs fails as a result.

Here is an example based on the current working state of #99, crucially lines like these:

In:

import random
from dimsim.compute.prep import compute_configs_from_data_entries

def test_density_and_dielectric_produce_same_compute_config():

    density_entry = {
        "id": random.randint(10**15, 10**16 - 1),  # random 16-digit integer
        "tag": "density",
        "x": [1.0],
        "smiles": ["[C:1]([O:5][C:3]([C:2]([O:4][H:13])([H:9])[H:10])([H:11])[H:12])([H:6])([H:7])[H:8]"],
        "temperature": 293.15,
        "pressure": 1.0,
        "value": 0.96488,
        "std": 0.00005,
        "units": "g/mL",
        "source": "",
    }

    dielectric_entry = {
        "id": random.randint(10**15, 10**16 - 1),  # random 16-digit integer
        "tag": "dielectric_constant",
        "x": [1.0],
        "smiles": ["[C:1]([O:5][C:3]([C:2]([O:4][H:13])([H:9])[H:10])([H:11])[H:12])([H:6])([H:7])[H:8]"],
        "temperature": 293.15,
        "pressure": 1.0,
        "value": 11.76,
        "std": 0.02,
        "units": "dimensionless",
        "source": "",
    }

    properties = [density_entry, dielectric_entry]

    compute_configs = compute_configs_from_data_entries(
        data_entries=[density_entry, dielectric_entry],
        force_field="openff-2.1.0",
        n_molecules=600,
    )

    assert len(compute_configs) == 1, f"compute configs differ in density field: {[config['density'] for config in compute_configs]=}"

Out:

>       assert len(compute_configs) == 1, f"compute configs differ in density field: {[config['density'] for config in compute_configs]=}"
E       AssertionError: compute configs differ in density field: [config['density'] for config in compute_configs]=[0.96488, None]
E       assert 2 == 1
E        +  where 2 = len([{'tag': 'liquid', 'force_field': 'openff-2.1.0', 'n_molecules': 600, 'smiles': ['[C:1]([O:5][C:3]([C:2]([O:4][H:13])([H:9])[H:10])([H:11])[H:12])([H:6])([H:7])[H:8]'], ...}, {'tag': 'liquid', 'force_field': 'openff-2.1.0', 'n_molecules': 600, 'smiles': ['[C:1]([O:5][C:3]([C:2]([O:4][H:13])([H:9])[H:10])([H:11])[H:12])([H:6])([H:7])[H:8]'], ...}])

dimsim/_tests/compute/test_prep.py:40: AssertionError

On one hand, ignoring target density when provided by experiment feels like a waste. On the other hand, we're already going to be preparing many liquid boxes without knowing a target density and treating them all the same³ makes de-duplication work more nicely.

Footnotes

1. Some chemical composition, temperature, pressure ↩

2. i.e. identical chemical composition, etc. ↩

3. It's possible we could keep a running tally of these targets in a database somewhere ... ↩

[mattwthompson]

It's hard for me to parse how Evaluator ultimately sets up its boxes, but I don't see it wired through in the same way. That's another point in favor of not using the target value when setting things up

[lilyminium]

Evaluator doesn't use the target value, it packs everything at (some transform of) 0.95 g / mL IIRC.

I'm mostly in favour of starting at the known density if we can, but with the concern that it may not scale well to batching lots of different boxes without explosions; I believe Evaluator packs extremely loosely to get around this, with the downside that equilibration might take longer.

Could deduplication ignore densities maybe and just compare everything else? I'm not sure if the equality check right now just compares the dicts, but it seems to me you would want to have a custom equality function anyway, as right now swapping the order of SMILES would already cause issues (e.g. 'smiles': ['C1CCCCC1', 'CCCCCC'] vs 'smiles': ['CCCCCC', 'C1CCCCC1']).

[mattwthompson]

Thanks - that's a good idea. I implemented this in 1248f8f; it'll need to live elsewhere but I am deferring that until later since I don't want that PR to also revamp the submission layer.