> I assume it works like this that OB determines the atom type to be HO (H
> bound to O).
No, no. This file is like a big translation dictionary. It says "if an atom
type comes in from a PCModel file with atom type X," that's equivalent to ..
well, everything on that row. Obviously, this need n
I guess I spoke without thinking. What I'm getting at is that it would
be nice to see test cases to verify that everything's working as it
said before and after. Next time I'll just come out and say it :-)
- Noel
On 26 April 2013 10:37, David van der Spoel wrote:
> On 2013-04-26 11:17, Noel O'Bo
On 2013-04-26 11:17, Noel O'Boyle wrote:
> It's always good to link changes in the code to specific bugs that
> need fixing. It may be useful to see whether you identify such cases
> here before you spend time on this. If you decide to go ahead, I would
> suggest that you add some test cases to ens
It's always good to link changes in the code to specific bugs that
need fixing. It may be useful to see whether you identify such cases
here before you spend time on this. If you decide to go ahead, I would
suggest that you add some test cases to ensure that existing correct
behaviour is retained.
On 2013-04-26 07:36, David van der Spoel wrote:
> On 2013-04-26 05:38, Geoffrey Hutchison wrote:
>>> I'm looking at types.txt and wondering whether not the internal
>>> representation of atom types (INT) should be unique? Now there are three
>>> HO, two H, three C3 etc.
>>
>> IIRC, the issue is tha
