On 17 December 2011 04:46, Geoff Hutchison wrote:
>> The weird thing is that IdentifyResidue can identify the first serine
>> without any problems; it just doesn't identify the second one. Also,
>> it will identify them both correctly if the --gen3d is omitted (or
>> more precisely, if the call to
> The weird thing is that IdentifyResidue can identify the first serine
> without any problems; it just doesn't identify the second one. Also,
> it will identify them both correctly if the --gen3d is omitted (or
> more precisely, if the call to Builder.Build is omitted).
This bug report exposed tw
> That would be great. Yes - the previous functions return true. But if
> I understand correctly, they are setting flags used by later
> calculations, and it may be that the problem is already caused at this
> stage?
Indeed. I can't see the exact problem yet, but it's clear that the
TracePeptideC
On Dec 13, 2011, at 2:25 AM, Noel O'Boyle wrote:
> Also, it will identify them both correctly if the --gen3d is omitted (or
> more precisely, if the call to Builder.Build is omitted).
Wait… If I just use the SMILES string, it works? That explains why the unit
test didn't catch this.
I'll set a
On 12 December 2011 22:34, Geoffrey Hutchison wrote:
> I've done a lot of debugging in chains.cpp, but don't have time for a few
> days. It's sorta like a specialized SMILES/SMARTS parser.
>
>> result = DetermineHetAtoms(mol) && result;
>> result = DetermineConnectedChains(mol)
I've done a lot of debugging in chains.cpp, but don't have time for a few days.
It's sorta like a specialized SMILES/SMARTS parser.
> result = DetermineHetAtoms(mol) && result;
> result = DetermineConnectedChains(mol) && result;
> result = DeterminePeptideBackbone(mol) &&
Hi there,
I've been looking at bug PR#3448379. It's a failure in identifying a
serine when at the C-terminus, after calling --gen3d (it's labelled as
UNK).
As a simpler testcase, "obabel -:N[C@@H](CO)C(=O)N[C@@H](CO)C(=O)O
--gen3d -opdb" will cause the problem (two serines in a row). To speed
thi
