testing/convert.py DesmondToDesmond 'not a double @:0 in'

[jandom]

This is the bug that Ellen introduced me to

Steps to reproduce

git clone Intermol
cd InterMol/testing
python convert.py -i Inputs/Desmond/lck_solvent/lck_Me_Cl_solvent_12_1-out.cms -o Outputs/DesmondToDesmond/lck_solvent/desmond_converted.cms -d $SCHRODINGER -e

The error message is

Total energy from /home/jandom/workspace/InterMol/testing/Inputs/Desmond/lck_solvent/system.enegrp.dat:
4.73480879e+04
RuntimeError: Job failed with non-zero return code (250).

Failed evaluating energy of /home/jandom/workspace/InterMol/testing/Outputs/DesmondToDesmond/lck_solvent/desmond_converted.cms

Inspecting the desmond log shows

less /home/jandom/workspace/InterMol/testing/Outputs/DesmondToDesmond/lck_solvent/system.log
In C++ termination handler due to uncaught exception of type std::invalid_argument
what: not a double @:0 in 

The reason for this bug is a missing column in the ffio_dihedrals: it has columns c0-c6, but for a 'proper-trig' dihedral type it should be c0-c7. If you manually inject a 7th column filled with zeros, desmond can compute the energies.

This concludes the main bug. Other than that the files look okay. The number of atoms and ct_blocks is the same

grep "m_atom\[" Inputs/Desmond/lck_solvent/lck_Me_Cl_solvent_12_1-out.cms
  m_atom[3222] { 
  m_atom[3129] { 
  m_atom[48] { 
  m_atom[45] { 
grep "m_atom\[" Outputs/DesmondToDesmond/lck_solvent/desmond_converted.cms
  m_atom[3222] {
  m_atom[3129] {
  m_atom[48] {
  m_atom[45] {

One thing that I would consider a bug is re-ordering of atoms in the input: the ligand atoms are moved from the begging of the 1st ct_block in the input to the end of the block in the convert. But that's another story.

[jandom]

Just saw issue #36 – you guys are fast – this ticket is likely irrelevant ;)

[mrshirts]

Hi, Jan-

Yep -- the information Ellen gave in group meeting ("the number of dihedral terms") was enough for me to zero in on the problem over the weekend, and fix the issues that was causing Desmond to crash. The dihedrals are currently not right, but they are functional at least.

The ordering of atom blocks is an interesting case. I would argue that it's not actually a bug. Because there are frequently multiple ways to represent a molecular system within the same software that are equivalent, InterMol is only required to print out an ASCII representation that gives the same Hamiltonian in the simulation software. Changing the ordering of atoms does not change the Hamiltonian, thus preserving atom order is not currently required. We may change at some point, but for now, atom reordering is explicitly allowed.

It's certainly true that this point needs to be explicitly stated more clearly.