You are here

remodel gives no output

4 posts / 0 new
Last post
remodel gives no output

Dear all,

I am following the tutorial

I am using version 2017.52, and run command "nohup remodel.static.macosclangrelease -s 1pgaA_0001.pdb -blueprint template.blueprint -jd2:no_output -num_trajectory 1 -save_top 1 -out:prefix long_loop -remodel:quick_and_dirty > output.txt"

The output.txt was attached. No long_loop_1.pdb can be found.

Many thanks.

output.txt30.02 KB
Post Situation: 
Tue, 2018-03-06 07:40

Are you specifically looking for `long_loop_1.pdb`? Because from the tracer output, that doesn't seem to be what the name of the output file is going to be:

protocols.jd2.JobDistributor: long_loop1pgaA_0001_0001 reported success in 20 seconds

Typically you expect the output PDBs to be named according to the job name. So for this job, I'd expect an output file named `long_loop1pgaA_0001_0001.pdb`. (This is actually a combination of your `-out:prefix` setting, the name of the input structure being used, and an additional `_0001`, representing that it's the first model of potentially mulitple models (normally controlled by the `-nstruct` option.) from that input structure.)

That is, of course, if you're expecting PDB output. While this is the default for many Rosetta protocols, some have different defaults (e.g. outputting as a silent file), and you can often change how you get the output by changing the flags you pass.

That latter bit is actually why you're not getting any output. You're passing the flag `-jd2:no_output` which, not surprisingly, turns off structure output. If you remove that option, you should get an output PDB.

Tue, 2018-03-06 07:52

Thank you very much for reply.

When I check, it says. "Normally the job distributor will write out a file at the end of a run, usually in the format of XXXX_0001.pdb; this file is NOT TO BE TRUSTED." I do not know whether this is the reason in the tutorial "-jd2:no_output" was used. I actually tried to remove "-jd2:no_output", it gives long_loop1pgaA_0001_0001.pdb with an unclosed loop, which seems consistent with the statement "not to be trusted". The document also asks me to "look for files that are simply 1.pdb, 2.pdb, etc".

Tue, 2018-03-06 08:48

Hmm ... I see. I think you're right. -- I'm not entirely familiar RosettaRemodel, so I was unaware of that. In that case, yes, -jd2:no_output is a flag that you probably want to have on.

I think what might be happening can be found in these lines from the log file

protocols.forge.remodel.RemodelMover: ** boost_closure_stage
protocols.forge.remodel.RemodelMover: at least one loop is beyond tolerance
protocols.forge.remodel.RemodelMover: * 0 / 1   closed / attempts 
protocols.forge.components.VarLengthBuild: centroid_build: loop: 20-25, final chainbreak = 2.21748, max_linear_chainbreak_: 0.07
protocols.forge.components.VarLengthBuild: centroid_build: final chainbreak at 23 = 2.21748 max tolerance 0.07
protocols.forge.remodel.RemodelMover: centroid_build(): variable length build failed. resetting pose to archived pose.
protocols.forge.remodel.RemodelMover: centroid_build(): centroid_build unable to close loop. retrying.
protocols.forge.remodel.RemodelMover: apply(): number of attempts at loop closure made: 1
protocols.forge.remodel.RemodelMover: clustered poses count: 0
protocols.forge.remodel.RemodelMover: Remodel poses remaining from original run: 0


So it looked like Remodel tried to close the loop, but in the end the attempt was unsuccessful. It says it was retrying to close the loop, but it looks like there's a limit of one try in the loop closing stage, so it canceled that model. Since it's only building one model, it fails that model and doesn't output anything.

There's two options it looks like you can play with. The first I'd try is -remodel:RemodelLoopMover:allowed_closure_attempts  Increasing this number will allow repeated attempts at closing the loop. Even if the first closure attempt fails, often subsequent closure attempts may succeed.  The other one you may want to try is -remodel::num_trajectory. This sets the number of model attempts. It's at a higher level than the loop closure, so there might be something in the initial stages which can change which will allow you to better attempt the loop closure.

Wed, 2018-03-07 08:44