- This topic has 11 replies, 3 voices, and was last updated 11 years ago by Anonymous.
December 5, 2012 at 3:08 pm #1480Anonymous
I do fragment-based loopmodeling which is performing well. Now I want to add a distance constraint to have a disulfide bond between two cysteines but something is going wrong and I get no output. What am i doing wrong?
My input file is:
mpirun -np 10 /opt/soft/rosetta3.4/rosetta_source/bin/loopmodel.mpi.linuxgccrelease -in:file:fullatom -loops:input_pdb mc4.pdb -loops:loop_file mc4.loop_file -loops:frag_sizes 9 3 1 -loops:frag_files mc4_09 mc4_03 none -loops:remodel quick_ccd -loops:refine refine_kic -loops:relax fastrelax -loops:extended -loops:ccd_closure -loops:random_loop -in::file::psipred_ss2 mc4.psipred_ss2 -nstruct 10000 -constraints:cst_file mc4.cst -constraints:cst_weight 10.0 -out:file:silent mc4_silent.out -database /opt/soft/rosetta3.4/rosetta_database
and the constraint file is:
AtomPair SG 257 SG 263 HARMONIC 2.0 0.1
What should I change?
Thank you very much in advance!
December 5, 2012 at 3:58 pm #8169Anonymous
Does “no output” mean “no mc4_silent.out” file, or “no logging output whatsoever”? If the former, can you post what logging output you have (maybe just the first 20 and last 20 lines if it’s long)? How long does the Rosetta process run? Does it also fail when not run in MPI?
I’m reasonably certain the loop model executable MPI works differently from most MPI in rosetta; it expects you to create 10 output directories (because you used -np10). See this thread: http://www.rosettacommons.org/content/loop-modelling-error-rosetta32-or-rosetta33
I’m not sure what loop model MPI does with silent output, though.
December 10, 2012 at 11:28 am #8202Anonymous
When I run it without MPI, I get no output at all. I think it does not even start the calculation.
When I run it with MPI I get the output attached to this mail. It shows a problem with Rosetta but what I don’t understand is that without constraints my calculations run perfectly with and without MPI.
PS: When running on MPI each processor creates its own silent output file.
December 11, 2012 at 5:28 pm #8217Anonymous
Thank you very much for your help!
I have come a bit further but I keep getting “core::id::EXCN_AtomNotFound” although I have set the flag “-ignore_zero_occupancy false” and there are no more zero occupancy atoms. I also think that Rosetta sees the right cysteine residues because I get the output “Detecting disulfides”.
So which could be the atoms that Rosetta can’t see?
December 11, 2012 at 6:12 pm #8219Anonymous
Yes I have tried your suggestions but it didn’t change anything.
I upload one of the log files but the error message isn’t shown in any of them. Also the “-constraints:exit_on_bad_read true” didn’t change anything.
The strange thing is that I get some output, for example now I was running it on 6 processors, and I got 3 output structures before the “core::id::EXCN_AtomNotFound” appeared and Rosetta crashed. What I also don’t understand is that Rosetta tells that it found the disulfide bond but the disulfide bond is not present in any of the output structures.
Running Rosetta without any constraint works without any problem.
December 12, 2012 at 12:54 pm #8225Anonymous
I have tried your suggestion but still the calculation gets killed soon after and the few output models that I get don’t have the disulfide bond
December 12, 2012 at 5:37 pm #8227Anonymous
A small update:
When running Rosetta locally without mpi the calculation very quickly stops “waiting for job request”. The process itself keeps running at 100% CPU use.
It happens with and without constraints so I’m not sure whether it is important.
December 10, 2012 at 6:42 pm #8210Anonymous
The constraint file numbering is pose numbering. This means if your lose any of the residues from the input structure, you’ll change numbering. In the mpi-error.txt, you’ll see a bunch of “PDB reader is ignoring atom”, which includes most of residues 14-19. This means residues 257 and 263 are probably not what you think they are. Thus the “terminate called after throwing an instance of ‘core::id::EXCN_AtomNotFound'” when you include constraints. Residues 257 and 263 as far as Rosetta are concerned aren’t cysteines, and thus wouldn’t have atom SG.
Try running with “-ignore_zero_occupancy false” and see if that helps.
December 10, 2012 at 7:56 pm #8213Anonymous
Do what Rocco said first. For MPI, you can use the flag -mpi_tracer_to_file $filestem, which will cause each MPI process to write to its own file named filestem_# (filestem is a stem of your choice; # is the processor number). This will make the log files more legible.
You can also try A) adding a chain ID to your PDB, and then recasting your constraints file into PDB numbering (AtomPair SG 257A SG 263A HARMONIC 2.0 0.1) to tell Rosetta to use PDB numbering instead of pose numbering. (Fixing the occupancies manually, or with -ignore_zero_occupancy false” is a superior solution.
December 11, 2012 at 5:33 pm #8218Anonymous
Did you try any of the stuff in my previous post?
Also, you can try -constraints:exit_on_bad_read true to see if that changes the error trajectory (bad constraint read, or errors somewhere else?)
December 11, 2012 at 8:25 pm #8222Anonymous
The message “Detecting disulfides” only means that it is running the disulfide detection algorithm, not that it found any disulfides.
Note that there’s nothing in the constraint file you’re giving it that annotates that this AtomPair constraint is a disulfide. You’re externally imposing an atom pair constraint that’s separate from the internal disulfide interactions.
What might be happening is that as loop modeling switches back and forth between centroid and full atom mode, Rosetta may be trying to apply the full atom constraints when the cysteine is in centroid mode and thus lacks the SG atom. As Rosetta is apparently autodetecting the disulfides if the residues are close enough, you can possibly relax your constraints. Instead of constraining the sulfurs themselves, try constraining the CB-CB distance instead (constrain it to below 3.7 Ang or so, and the auto-detection code should probably be able to pick it up). CB exists in both the centroid and full atom modes, so the constraint to CB shouldn’t result in AtomNotFound errors if the full atom/centroid switching is the cause of your problem.
December 12, 2012 at 9:23 pm #8230Anonymous
If you’re running the mpi-compiled program without the mpirunner, hanging doing nothing is expected. Usually the first node in the MPI cluster is the master/IO node, so it doesn’t do any calculation itself. It just sits there, waiting for the other nodes to check in. Since there are no other nodes, it doesn’t do anything. If you want to run a single node, you need to compile without the extras=mpi option. (Both can coexist in the same directory tree, though the two-part executables are the last compiled version. Explicitly reference the *.mpi.* or *.default.* ones to be sure.)
Regarding the errors you see, at this point I’m a little stumped. I’d try variations on the protocol, and see if you get the same errors. E.g. try perturb_kic or perturb_ccd instead of quick_ccd. Try different loops in your loop file (perhaps try a single loop at a time.) Try omitting some of the optional options from your command line.
If you can minimize the example (mainly try using perturb_kic to avoid fragement file dependance) and put together the input files we would need to replicate it (I think we’re just missing the loops file at this point), I could possibly start poking around with it locally, which may lead to a better understanding of what’s going on.
- You must be logged in to reply to this topic.