BBK* issue when omitting wildtypes

[bbpezeshki]

It seems that, for some designs, BBK* is not happy omitting wildtypes, whereas other times it is fine.

I attach a zip file of the test script you've provided with the following changes:

• it set to omitting wild-types
• it is set to run all designs in the design folder
• a folder _design_repository that holds various designs to test
• focusing on only one design (design 00008 and various modifications of it) with extraneous files removed.

bbkstar_omit_wildtypes.zip

There are four design files that I will refer to that can be found in the _design_repository folder:

• design_00008.toml
  ----- original 00008 multistate design
  ----- result in less than half a minute
• design_00008_phe_hid-ARG-GLY.toml
  ----- first mutable residue set to the wildtype [ "PHE" ]
  ----- second mutable residue considers [ "HID", "ARG", "GLY" ]
  ----- result in seconds
• design_00008_phe-HIP_ARG.toml
  ----- first mutable residue considers [ "PHE", "HIP" ]
  ----- second mutable residue set to [ "ARG" ]
  ----- no result after hours!
• design_00008_HIP_ARG-GLY.toml
  ----- first mutable residue considers [ "HIP" ]
  ----- second mutable residue set to [ "ARG", "GLY" ]
  ----- no result after hours!
  ---------- printout does not show what residue it is refining

The first two are already in the design folder, so from the bin folder you can simply run markstar.bbkstar.py to verify that both their results are computed in under a minute.

However, if you switch out the first two designs with the last two [and assuming my issue is reproducible] you/ll find it will not converge to a solution after hours.

Some Background:
We are trying to guide BBK* to find a solution with HIP in the first mutable position for design 00008 because the algorithm we are testing found the best K* solution for design 00008 as with having HIP assigned to the first mutable residue (whereas BBK*'s solution uses the wildtype PHE for the first position) and the solution with HIP has a higher K* than the solution produced by PHE. However, our algorithm does currently perform any domain specific pruning such as pruning sequences whose dissociate ligand or protein Z values are significantly lower than the wildtype, so this could be a cause of the difference.

So, I wonder if the result we are observing (both with the different K* values and with being unable to guide BBK* to find solutions with HIP as the first mutable residue) has to do with sequences being invalidated due to dissociate protein or ligand instability. Or, if not, what might be causing this.