Unassigned `current_directive` when merging protein+ligand

[davidlmobley]

Description

We were trying to use an experimental feature (via INTERCHANGE_EXPERIMENTAL) to merge a protein+ligand complex for simulation and encountered an issue where we get an UnboundLocalError: cannot access local variable 'current_directive' where it is not associated with a value; it's unclear what this means/how to fix.

Reproduction

Attached Jupyter notebook and input files. This comes from work of new student @kphuynh118 in my group so if additional files are needed she can likely provide.

GitHub doesn't want to let me to attach top/gro/sdf for some reason, so files are here on Dropbox

Output

---------------------------------------------------------------------------
UnboundLocalError                         Traceback (most recent call last)
Cell In[11], line 2
      1 os.environ["INTERCHANGE_EXPERIMENTAL"]="1"
----> 2 protein_interchange = Interchange.from_gromacs("protein.top", "protein.gro")
      3 complex_interchange = protein_interchange + ligand_interchange

File ~/miniforge3/envs/drugcomp1/lib/python3.12/site-packages/openff/interchange/_experimental.py:35, in experimental.<locals>.wrapper(*args, **kwargs)
     26 if os.environ.get("INTERCHANGE_EXPERIMENTAL", "0") != "1":
     27     raise ExperimentalFeatureException(
     28         f"\n\tFunction or method {func.__name__} is experimental. This feature is not "
     29         "complete, not yet reliable, and/or needs more testing to be considered suitable "
   (...)
     32         "INTERCHANGE_EXPERIMENTAL=1.",
     33     )
---> 35 return func(*args, **kwargs)

File ~/miniforge3/envs/drugcomp1/lib/python3.12/site-packages/openff/interchange/components/interchange.py:875, in Interchange.from_gromacs(cls, topology_file, gro_file)
    871 from openff.interchange.interop.gromacs._import._import import from_files
    872 from openff.interchange.interop.gromacs._interchange import to_interchange
    874 return to_interchange(
--> 875     from_files(
    876         top_file=topology_file,
    877         gro_file=gro_file,
    878     ),
    879 )

File ~/miniforge3/envs/drugcomp1/lib/python3.12/site-packages/openff/interchange/_experimental.py:35, in experimental.<locals>.wrapper(*args, **kwargs)
     26 if os.environ.get("INTERCHANGE_EXPERIMENTAL", "0") != "1":
     27     raise ExperimentalFeatureException(
     28         f"\n\tFunction or method {func.__name__} is experimental. This feature is not "
     29         "complete, not yet reliable, and/or needs more testing to be considered suitable "
   (...)
     32         "INTERCHANGE_EXPERIMENTAL=1.",
     33     )
---> 35 return func(*args, **kwargs)

File ~/miniforge3/envs/drugcomp1/lib/python3.12/site-packages/openff/interchange/interop/gromacs/_import/_import.py:50, in from_files(top_file, gro_file, cls)
     46     current_directive = stripped[1:-1].strip()
     48     continue
---> 50 if current_directive == "defaults":
     51     (
     52         nonbonded_function,
     53         combination_rule,
   (...)
     56         coul_14,
     57     ) = _process_defaults(line)
     59     system = cls(
     60         nonbonded_function=nonbonded_function,
     61         combination_rule=combination_rule,
   (...)
     64         coul_14=coul_14,
     65     )

UnboundLocalError: cannot access local variable 'current_directive' where it is not associated with a value

Software versions

This is on OS X via a mamba install. @kphuynh118 can you add the output of conda list?

[kphuynh118]

Here is the list of version of all packages installed

versions.txt

[mattwthompson]

Thanks for the detailed reproduction @kphuynh118 and @davidlmobley! I agree that's a surprising result, and I know exactly where the failure stems from. Independently of properly fixing this, that error could be improved.

The problem is that the #include pattern is not currently supported in importing GROMACS files, or if it's supported it's not yet tested for more than a few easy cases, mostly owing to $GMXDATA not be wired up correctly.

I'll get back to you later on whether or not there's a feasible and relatively safe workaround.

[davidlmobley]

Ah, ok, so if we want this to work we should fill in the includes ourself first? But yes,it would be handy if there were a message that told us that, haha

…

On May 6, 2025, 4:46 PM -0400, Matt Thompson ***@***.***>, wrote: mattwthompson left a comment (openforcefield/openff-interchange#1212) Thanks for the detailed reproduction @kphuynh118 and @davidlmobley! I agree that's a surprising result, and I know exactly where the failure stems from. Independently of properly fixing this, that error could be improved. The problem is that the #include pattern is not currently supported in importing GROMACS files, or if it's supported it's not yet tested for more than a few easy cases, mostly owing to $GMXDATA not be wired up correctly. I'll get back to you later on whether or not there's a feasible and relatively safe workaround. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[mattwthompson]

This is spawning a tree of improvements

• Improve errors when parsing GROMACS files #1224 should make this error should be significantly less cryptic
• Treat asterisks as comments in GROMACS topology files #1225 skips over lines with asterisks, which I only just now learned seem to be valid as comment tokens
• Look in $GMXDATA for missing force fields #1226 might be the beginning of reading force fields from GMXDATA, which is a huge feature which GROMACS practitioners sometimes take for granted
• Some logic inside of GROMACS topology files are not supported, which I'll get to later (either by supporting or skipping)

This might take a couple of weeks to get into a release, given the amount of testing and human review changes like this warrant. If you're really eager to get this going, I can set you up on a development build with a couple of tweaks that might enable this, but that involves you taking on some extra burden that you're not at all obliged to deal with

[davidlmobley]

Thanks for this, Matt. I think we're trying it out, though likely slowly, as we came up with another workaround. But this sounds like very helpful stuff; much appreciated. (You can probably mark this closed once you are ready to do so!)

[mattwthompson]

Great, thanks - the last two bullet points above are bigger tasks so I'm glad you can work around the current limitations