Subject: Re: Alignment sequence not found in PDB file
From: Karsten Suhre <>
Date: Fri, 16 Aug 2002 20:07:54 +0200
Cc:
Organization: IGS
Thank for that hint - but that wasn't it neither.
However, by shuffling around the lines in my input files, I got things
eventually working.
Is it true that the order of the structures in the alignment file has to be
the same as that in the SET KNOWNS command (maybe I missed this in the
manual)?
Kind regards, Karsten.
On Friday 16 August 2002 19:28, you wrote:
> I know this might sound like a wichcraft, but I was just helping a fellow
> MODELLER off the list, who had a similar problem, and I found out that
> non-visible 'return' sign at the end of his SET OUTPUT_CONTROL line was
> causing MODELLER not to read in PDB structure. After I entered 'return'
> and deleted the created new empty line (where this coruptet 'return'
> simbol was) everything was fine.
>
> I think this might have to do how some text editors interpret carry-over
> ASCII simbol.
>
> As for more log info, OUTPUT_CONTROL is the only way. Excceptions
> are some commands that have switches for their outputs (i.e. LONG, SHORT,
> etc).
>
> Good luck,
> Bozidar Yerkovich
>
> On Fri, 16 Aug 2002, Karsten Suhre wrote:
> > Hi!
> >
> > I already tried that - even set it to 2. But the fifth flag only controls
> > dynamics memory allocation prints, which is not my problem here. I guess
> > that something in my PDB file doesn't correspond to what modeller expects
> > (my program runs with other PDB files).
> >
> > Does anybody know which entries modeller reads and checks?
> >
> > I had a similar problem reading the PIR alignments. You really need to
> > put exactly 9 :'s into the header, and you must give the residues in
> > upper case - while t_coffee writes them out in lower case. That problem I
> > solved by experimentation. What I am seeking here is a way to obtain some
> > more verbose output when modeller has problems reading my input
> > (especially when you modify your alignments by hand errors slip in very
> > easily).
> >
> > Thanks a lot for giving my problems some consideration,
> >
> > Kind regards, Karsten.
> >
> > On Thursday 15 August 2002 23:58, Bozidar Yerkovich wrote:
> > > Replace the last zero in OUTPUT_CONTROL to 1. That will give you more
> > > info...
> > >
> > > Bozidar
> > >
> > > On Thu, 15 Aug 2002, Karsten Suhre wrote:
> > > > Hi!
> > > >
> > > > when I get the following error message, I understand that the
> > > > sequence in my PDB file does not correspond to that read from the
> > > > alignment. Up to know, it was what had happened, and I always found
> > > > the problem by trial and error, but this time .... :-(
> > > >
> > > > rdpir___648E> Alignment sequence not found in PDB file: 2
> > > > ./1EL3.pdb
> > > >
> > > > Is there some command or switch in modeller to get some more
> > > > information on what the problem is? i.e. which amino acid does not
> > > > match?
> > > >
> > > > Thank you very much for any hint,
> > > >
> > > > Karsten.
> > > >
> > > >
> > > >
> > > > PS: here my commands:
> > > >
> > > > SET OUTPUT_CONTROL = 1 1 1 1 0
> > > > READ_ALIGNMENT FILE = 'tcoffee.aln', ALIGN_CODES = 'all'
> > > >
> > > > and the output:
> > > >
> > > >
> > > > Job starting time (YY/MM/DD HH:MM:SS): 2002/08/15 23:41:12.615
> > > >
> > > > TOP_________> 2 2 READ_ALIGNMENT FILE = 'tcoffee.aln',
> > > > ALIGN_CODES = 'all'
> > > >
> > > > openf5__224_> Open 11 OLD SEQUENTIAL tcoffee.aln
> > > > openf5__224_> Open 13 OLD SEQUENTIAL ./1EL3.pdb
> > > > openf5__224_> Open 11 OLD SEQUENTIAL tcoffee.aln
> > > > openf5__224_> Open 13 OLD SEQUENTIAL ./1EL3.pdb
> > > > rdpir___648E> Alignment sequence not found in PDB file: 1
> > > > ./1EL3.pdb recover____E> ERROR_STATUS >= STOP_ON_ERROR: 1
> > > > 1
> > > >
> > > > Dynamically allocated memory at finish [B,kB,MB]:
> > > > 8065909 7876.864 7.692
> > > >
> > > >
> > > > PPS: Attached are the input files (there is only one sequence in the
> > > > alignment including gaps .. and the PDB file does only contain ATOM
> > > > lines. That's because I eliminated all other stuff to see whether the
> > > > error changes .. it doesn't, and I compared the sequences between the
> > > > PDB file and the alignment - they are identical).