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: AA_Canutescu@fccc.edu [mailto:AA_Canutescu@fccc.edu] 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, "AA_Canutescu@fccc.edu" AA_Canutescu@fccc.edu > 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 bozidar@salilab.org: > > > >> > >> Hi, > >> > >> Loop is definitely supported ;-). I'll see what's going on. > >> > >> Best, > >> Bozidar > >> > >> > >> On 10/4/02 1:18 PM, "AA_Canutescu@fccc.edu" AA_Canutescu@fccc.edu > >> 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 bozidar@salilab.org: > >>> > >>>> > >>>> 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, "AA_Canutescu@fccc.edu" > >>>> AA_Canutescu@fccc.edu > >>>> 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 > >>>> > >>>> > >>> > >> > >> > > > >