Dear Adrian,
A simple answer to your question is: you specified a non-existing
segment of the protein for the loop optimization:
SELECTION_SEGMENT = '151:0' '154:0', SELECTION_STATUS = 'initialize'
In your pdb file there is no '0' chain:
ATOM 1165 CD2 LEU 150 44.348 42.655 43.046 1.00 15.23 C
ATOM 1166 N GLY 151 0.000 0.000 0.000 1.00 16.38 N
ATOM 1167 CA GLY 15 0.000 0.000 0.000 1.00 15.57 C
This results in MODELLER selecting the whole protein to perform 'loop'
routine on it:
Number of all, selected real atoms : 1480 1480
Another thing I noticed is that you have compresses all the residues you
are selecting into one point? Is there any specific reason for this?
ATOM 1166 N GLY 151 0.000 0.000 0.000 1.00 16.38 N
ATOM 1167 CA GLY 151 0.000 0.000 0.000 1.00 15.57 C
ATOM 1168 C GLY 151 0.000 0.000 0.000 1.00 16.31 C
MODELLER complains about this though, but it keeps on:
serious non-bonded atom clash: 1143 1148 0.000
serious non-bonded atom clash: 1143 1149 0.000
serious non-bonded atom clash: 1143 1150 0.000
Energies are way off the charts:
Initial value of energy before optimization : 477452.2400
Current energy : 476905.9000
Maximal energy, step : 525495.1200
28
Minimal energy, step : 449273.2100
81
Average energy, stand.dev. : 506870.8100
15563.8500
What causes MODELLER to become a memory hog is the fact that you
unintentionally tried to perform an ab initio calculation of the whole
protein. I myself almost crashed our main Linux machine in the group,
running your top file. A job used up 92% of the available memory at one
point.
After I corrected the .top file:
SELECTION_SEGMENT = '151:' '154:', SELECTION_STATUS = 'initialize'
Energy returned to normal:
Initial value of energy before optimization : 27.4512
Current energy : 4.5270
Maximal energy, step : 67.8339
34
Minimal energy, step : 25.2391
363
Average energy, stand.dev. : 43.2928
10.7857
... and MODELLER produced a beautiful model ;-)
Summa sumarum:
One has to make sure that when s/he selects a segment of the protein,
using 'res_ID:chain_ID' convention (which is updated for the 6v2
release), that there is an existing chain_ID there. This is actually
quite a common mistake many users do: their pdb has a chain_ID, and they
omit it in their top file (just opposite of what you did).
I am still curious why you have compressed all the loop residues into a
single point (why those residues have all the coordinates equal to
zero)? It worked, because those resides were brought back into the
protein in the model MODELLER calculated, which is obviously good, and
their energy is also fine. If this is some empirical finding, and not
missing coordinates, I would certainly like to learn more about it.
...and there is no memory leak, thankfully ;-)
All the best and happy modeling,
Bozidar
-----Original Message-----
From: [">mailto:]
Sent: Wednesday, April 17, 2002 6:49 PM
To: Bozidar Jerkovic
Subject: Re: MODELLER
Dear Bozidar,
>
> Yes I am aware of this one. I think it may have to do with static vs.
> dynamic linking.
It's not obvious to me why could be a linking problem, but anyway it's
interesting this happens only for certain input files. For the input
data sets that generate this bug, the bug is repro(reproducible -all the
time). There is no situation(as far as I tested) in which for the same
input data to get the software working sometime and not working other
time. It just doesn't work -all the time - for that input data.
> What did you mean by "repro"?
An error that is exactly reproducible under any circumstances. It's used
in programers' jargon.
The other problem, that is actually the most serious one is also repro.
For certain input data sets, modeller starts allocating huge amounts of
memory (about 1GB/min on my machine). This indicates a serious memory
leak. I got my kernal crashed twice today because of this, so I have to
wait for your patch before using again modeller.
I will attach again an input data set that leads to this memory leak.
Everything is run on RedHat 7.2 on x86 architecture.
Thanks,
Adrian
>
> Thanks for these reports. It's sometimes hard for us to catch
> everything.
>
> Best,
> Bozidar
>
>
> On 17/4/02 5:33 PM, "" <>
> wrote:
>
> > Dear Bozidar,
> >
> > I have another problem to report, besides the memory leak one. For
> some
> > reasons, I got in certain situations the following error:
> >
> > ? FORTRAN Runtime Error:
> > ? Illegal character in numeric input
> > ? READ(UNIT=INTERNAL,...
> >
> > I wasn't able to track down any cause, and the error message is not
> very
> > explanatory to me. I would appreciate if you could give me a hint
> about this
> > sitation. This situation is a repro one, like also the memory leak
> one. I run
> > everything
> >
> >
> >
> > Thank you,
> >
> > Adrian
> >
> >
> > Quoting Bozidar Jerkovic <>:
> >
> >>
> >> Hi,
> >>
> >> Loop is definitely supported ;-). I'll see what's going on.
> >>
> >> Best,
> >> Bozidar
> >>
> >>
> >> On 10/4/02 1:18 PM, "" <>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I attached a tar.gz that contains top, log and pdb input file. In
> >> case 'loop'
> >>> routine is not anymore supported in mod6v1, what would be a get
> around
> >> for my
> >>> problem?
> >>>
> >>> Thanks for your help.
> >>>
> >>> Adrian
> >>>
> >>>
> >>> Quoting Bozidar Jerkovic <>:
> >>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Can you please send me your .top and .log and all input files and
> >> I'll
> >>>> run
> >>>> it here. I can't actually see which part of .top fails. I presume
> >> it's
> >>>> "CALL
> >>>> ROUTINE = 'loop' # do loop modeling", but I don't wanna
guess.
> >>>>
> >>>> Best,
> >>>> Bozidar
> >>>>
> >>>>
> >>>>
> >>>> On 8/4/02 3:24 PM, ""
> >>>> <>
> >>>> wrote:
> >>>>
> >>>>> Dear Bozidar,
> >>>>>
> >>>>>
> >>>>> I downloaded the last version of MODELLER and I am running into
> >> some
> >>>>> problems. For the time being, I use MODELLER mostly for loop
> >> modeling.
> >>>> Using
> >>>>> the
> >>>>> previous version(mod6a), I used to create a top file like this,
> and
> >>>> everything
> >>>>> worked ok:
> >>>>>
> >>>>> INCLUDE
> >>>>> SET OUTPUT_CONTROL = 1 0 0 1 0 # Set to 1 1 1 1 0 for
> >> debugging.
> >>>>> SET SEQUENCE = '1dysA_47-50'
> >>>>> SET LOOP_MODEL = '1dysA_47-50.pdb'
> >>>>> SET LOOP_MD_LEVEL = 'refine2' # refine3 - fastest
> >>>>> # refine2 - medium
> >>>>> # refine1 - most thorough SET
> >>>>> LOOP_STARTING_MODEL = 1 SET LOOP_ENDING_MODEL = 3 # number of
> >>>>> loop models
> >>>>> SET RAND_SEED = -38901 # change for different starting models
> >>>>> CALL ROUTINE = 'loop' # do loop modeling
> >>>>>
> >>>>> # Pick model residues that need to be refined.
> >>>>>
> >>>>> SUBROUTINE ROUTINE = 'select_loop_atoms' # Uncomment if you
> >>>>> also
> >> want
> >>>> to
> >>>>> optimize the environment:
> >>>>> # SET SELECTION_SEARCH = 'SPHERE_SEGMENT', SPHERE_RADIUS = 6
> >>>>> PICK_ATOMS SELECTION_SEGMENT = '47:A' '50:A', SELECTION_STATUS =
> >>>> 'initialize'
> >>>>> RETURN
> >>>>> END_SUBROUTINE
> >>>>>
> >>>>>
> >>>>> With the newest version of MODELLER that I downloaded last
> >>>>> week,
> >>>> doesn't work
> >>>>> anymore. I receive an error message in the end of.log file like
> >> this:
> >>>>>
> >>>>> act10___551E> No such routine:
> >>>>> recover____E> ERROR_STATUS >= STOP_ON_ERROR: 1 1
> >>>>>
> >>>>> Dynamically allocated memory at finish [B,kB,MB]:
> >>>> 28478873
> >>>>> 27811.400 27.160
> >>>>> Starting time :
> >> 2002/04/08
> >>>>> 14:20:40.274
> >>>>> Closing time :
> >> 2002/04/08
> >>>>> 14:20:51.421
> >>>>> Total CPU time [seconds] :
> >> 11.00
> >>>>>
> >>>>>
> >>>>> Could you help me please regarding this matter? Could you also
> tell
> >> me
> >>>> if
> >>>>> there is any dependency needed(some libraries, fortran, etc)? I
> >>>>> am
> >>>> using
> >>>>> RedHat
> >>>>> 7.2 with kernal 2.4.7-10
> >>>>>
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Adrian Canutescu
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>