SimTk/openmm — pull request #20 by rmcgibbo (2013-06-11 22:34:29+00:00)
Title: Avoid writing malformed output when the positions are too large.

@dermen reported [here](https://github.com/rmcgibbo/mdtraj/issues/87) that the PDB parser emits malformed data when the coordinates are large. The problem comes from [this](https://github.com/SimTk/openmm/blob/master/wrappers/python/simtk/openmm/app/pdbfile.py#L281) string formatting:

`ATOM %5d %-4s %3s %s%4d %8.3f%8.3f%8.3f 1.00 0.00" % (atomIndex%100000, atomName, resName, chainName, (resIndex+1)%10000, coords[0], coords[1], coords[2])`

Normally, this string formatting produces an output of length 66, e.g.

```
>>> len("ATOM %5d %-4s %3s %s%4d %8.3f%8.3f%8.3f 1.00 0.00" % (1,1,1,1,1,1,1,1))
66
```

But when one of the `coords` is too large, the fixed with `%8.3f` specifier silently overflows, and you get something like this.

```
>>> len("ATOM %5d %-4s %3s %s%4d %8.3f%8.3f%8.3f 1.00 0.00" % (1,1,1,1,1,1,1, 10000))
67
```
Then, the numbers are no longer in the columns that the PDB format expects them to be in, and you get a little chaos like this pdb file.

```
ATOM 1043 C XXX A 1 5440.61133429.05918685.440 1.00 0.00
ATOM 1044 C XXX A 1 5440.09433431.55618686.787 1.00 0.00
ATOM 1045 C XXX A 1 5441.66133431.52118684.366 1.00 0.00
ATOM 1046 C XXX A 1 5438.82833430.99318684.258 1.00 0.00
ATOM 1047 C XXX A 1 5442.92733432.08418686.896 1.00 0.00
```

Also, what is the procedure in OpenMM for testing the application layer? Does OpenMM have the infrastructure for application layer (python) unit tests?