Hello,
I downloaded last Friday's - 9/9/11 - Rosetta3.3 version (curious to try the "fastsaxs" scoring) but there seems to be a problem in Rosetta3.3 when handling constraints.
Running a script like the one posted elsewhere causes an exception under minirosetta 3.3, while 3.2 is able to run the very same script without problems. Here is what the message reads:
protocols.moves.MonteCarlo: QuickCCD trials= 450; accepts= 0.1111; energy_drop/trial= -7.19030
protocol.loops.LoopMover: Chainbreak: 0.00119666 Max: 0.2
protocols::checkpoint: Deleting checkpoints of Remodel
protocols::checkpoint: Deleting checkpoints of Loopbuild
protocols.jd2.JobDistributor:
[ERROR] Exception caught by JobDistributor for job S_TEMPLATE_0001Atom OVL1 132 not found
protocols.jd2.JobDistributor:
protocols.jd2.JobDistributor: S_TEMPLATE_0001 reported failure and will NOT retry
protocols.jd2.JobDistributor: no more batches to process...
protocols.jd2.JobDistributor: 1 jobs considered, 1 jobs attempted in 406 seconds
Interestingly, running a standard abinitio protocol with the same constraints under minirosetta 3.3 causes no error. So somehow either the comparative or the loop modeling protocol are probably faulty.
Best regards,
Marcel
I believe OVL1 to be one of the 'overlap' virtual atoms used to calculate loop closure for the chainbreak scoring term. Is position 132 supposed to be a loop cutpoint for your system?
Are you using the EXIT_THROWS_EXCEPTION compliation flag? I don't remember anyplace that throws atom not found exceptions (as opposed to just crashing immediately).
Yes indeed, position 132 is one of the cut points. May I have to set the "constraints:named" flag in 3.3?
I was not using any flag during compilation of Rosetta.
Are you using constraints as well...? If you have a constraint set on the OVL atoms, it is highly likely to cause problems like this, as those atoms may exist for only part of the run. That flag may help, I've never used it before.
Yes, that is what I wanted to say. The problem arises only in combination with constraints. The protocol without has no problems.
The minimal script consists of comparative modeling with symmetry option. If I include constraints in the protocol, Rosetta3.3 crashes (as described), whereas Rosetta3.2 does not. Although everything is the same and constraints indeed point at OVL atoms.
I thought that Rosetta3.2 might simply omit these constraints but I tested the run with ridiculous constraints (100 Angstrom between each amide proton within the loop). This resulted in a completely extended conformation of the respective loop.
In my opinion, this might indicate a difference in constraint handling between 3.2 and 3.3.
PS: The "constraints:named" flag does not help.
Well, the solution is to stop constraining the OVL atoms, since they aren't there all the time.
I suspect 3.2 "failed to fail" as opposed to working - it probably was giving incorrect values for the atom name lookup when OVL was not present, and constraining the wrong atoms. I know Rosetta at that time would let you specify nonexistent sidechain atoms when in centroid mode and silently fail to comment that the atoms did not exist (and use garbage atom IDs for the constraining); I suspect 3.2 was doing the same with your old OVL constraints.
Thank you for looking into this and for the advise. I think that should settle this issue. I am glad that 3.3 pointed this out.