[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory leak / kernel crash / missing chain_ID (fwd)



Dear Bozidar,

Thank you for help. Your hint(to put '' instead of '0') looks to work so far.
Regarding the fact that coordinates for the loop were zeroed, I did this in
order to get a de novo loop prediction.

Adrian

Quoting Bozidar Jerkovic <>:

> 
> 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
> > >>>> 
> > >>>> 
> > >>> 
> > >> 
> > >> 
> > > 
> > 
> > 
> 
>