using constraints with AbinitioRelax (Rosetta 3.1)

[Anonymous]

Hello all,

First, thank you to the devs and the Baker lab for this wonderful, nicely-documented, open-source package.

Second, with Rosetta 3.1, I’m trying to run a simple AbinitioRelax protocol using a C-alpha trace to constrain the backbone of the Rosetta models. I’m using coordinate constraints, yet my results for a 70-protein test set are statistically unchanged for constraints:cst_weight values of 0, 1, 100, and 10e5. What am I doing wrong, and is there a better way to achieve my goal?

I’ve also looked to apps/public/scenarios/ca_to_allatom.cc as a starting point for writing my own app, but despite the documentation and logical layout of the source code, I’m still a bit lost.

Any guidance would be greatly appreciated.

Sincerely,

Nasos Dousis

My script file looks like this:

||rosetta_source/bin/AbinitioRelax.linuxgccdebug
-database rosetta_database
-in:file:native pdb/${pdbid}.pdb
-in:file:frag3 fragments/aa${pdbid}_03_05.200_v1_3
-in:file:frag9 fragments/aa${pdbid}_09_05.200_v1_3
-constraints:cst_weight ${cst_weight}
-constraints:cst_file ${cst_file}
-out:nstruct 10
-out:file:silent ${out_dir}/${pdbid}${chainid}.silent
-out:pdb true
-out:path ${out_dir}
-out:sf ${out_dir}/${pdbid}${chainid}.fsc
-no_prof_info_in_silentout
-mute core.io.database||

and my cst_file is like this:

|||CoordinateConstraint CA 2 CA 2 -34.489 23.255 -2.312 HARMONIC 0.0 1.0
|CoordinateConstraint CA 3 CA 3 -34.258 20.103 -4.407 HARMONIC 0.0 1.0
|CoordinateConstraint CA 4 CA 4 -33.172 20.591 -8.075 HARMONIC 0.0 1.0
|CoordinateConstraint CA 5 CA 5 -33.930 17.924 -10.685 HARMONIC 0.0 1.0
|CoordinateConstraint CA 6 CA 6 -31.233 17.075 -13.244 HARMONIC 0.0 1.0
|CoordinateConstraint CA 7 CA 7 -32.272 14.848 -16.146 HARMONIC 0.0 1.0
|CoordinateConstraint CA 8 CA 8 -29.322 13.110 -17.796 HARMONIC 0.0 1.0
|CoordinateConstraint CA 9 CA 9 -29.294 11.326 -21.168 HARMONIC 0.0 1.0
|::.::
|::.::
|::.::
|CoordinateConstraint CA 81 CA 81 -30.231 16.089 -6.242 HARMONIC 0.0 1.0
|CoordinateConstraint CA 82 CA 82 -30.082 18.618 -3.430 HARMONIC 0.0 1.0
|CoordinateConstraint CA 83 CA 83 -27.581 21.483 -3.207 HARMONIC 0.0 1.0||

[Anonymous]

Don’t kid yourself – our documentation is terrible!

It might be not even reading your constraints. You should try passing it a garbage constraint file to see if it notices and crashes.

Does the output mention constraints anywhere? What does it say?

Does the scorefile mention a constraint term, and if so, does its weight change as you change the input weight?

I found some code that implies that the problem may be the constraint weight option – try using loopfcst::coord_cst_weight instead? (that’s…something garbled coordinate constraint weight).

[Anonymous]

Happy new year!

Thank you for your questions and suggestions. It took me a little while to re-run my test set with __loopfcst:coord_cst_weight __instead of __constraints:cst_weight__, but the RMSD means and variances did not change regardless of the weights that I chose (0, 0.01, 1, 1000). It appears that the constraint file is being read correctly (I can use the __constraints:dmp_cst_set __ feature and get back essentially the same constraint file), but the weights are not being applied, whether they are recognized or not.

Here’s the scorefile with __constraints:cst_weight=1000__

||SCORE: |score |vdw |cenpack |pair |env |cbeta |rg |hs_pair |ss_pair |rsigma |sheet |clashes_total |clashes_bb |description
SCORE: | -7.414 |3.060 |-10.959 |-13.238 |-34.528 |39.187 |46.637 |2.671 |-27.235 |-15.736 |2.726 |0.000 |0.000 |S_00000001
SCORE: |-23.680 |9.892 |-11.907 |-16.523 |-36.105 |36.933 |40.491 |2.738 |-32.290 |-17.254 |0.343 |1.000 |1.000 |S_00000002||

and the output snippet that mentions the constraints:

||core.scoring.constraints: Constraint choice: constraints.dat
core.io.constraints: read constraints from constraints.dat
core.io.constraints: read constraints section –NO_SECTION—
core.io.constraints: no section header [ xxx ] found, try reading line-based format… DON’T MIX
core.io.constraints: read constraints from constraints.dat||

Here’s the scorefile with __loopfcst:coord_cst_weight=1000__

||SCORE: |score |vdw |cenpack |pair |coordinate_constraint |env |cbeta |rg |hs_pair |ss_pair |rsigma |sheet |clashes_total |clashes_bb |description
SCORE: |28078380.206 |2.140 |-12.806 |-19.625 |28078392.256 |-32.807 |40.208 |44.134 |1.862 |-22.495 |-15.386 |2.726 |0.000 |0.000 |S_00000001
SCORE: |39294630.348 |1.758 |-15.278 |-17.152 |39294669.006 |-48.838 |37.422 |40.766 |6.210 |-27.845 |-16.045 |0.343 |0.000 |0.000 |S_00000002||

and the output snippet that mentions the constraints:

||core.scoring.constraints: Constraint choice: constraints.dat
core.io.constraints: read constraints from constraints.dat
core.io.constraints: read constraints section –NO_SECTION—
core.io.constraints: no section header [ xxx ] found, try reading line-based format… DON’T MIX
core.io.constraints: read constraints from constraints.dat||

Clearly the coordinate_constraint term is dominating the score, yet the aggregate results are unchanged. I’m looking more closely at __protocols: :abinitio: :ClassicAbinitio __to understand why, and I have two follow-up questions:

1. How and at what stage are constraints activated in __ClassicAbinitio__? I looked at __rosetta_database/scoring/weights/stageX.wts __but could not find any weights pertaining to constraints.

2. Are the coordinate constraints calculated as a best fit, i.e. automorphic superposition/RMSD? If not, is there a simple way to modify the coordinate constraint class to achieve this? If not, I’ll try to incorporate parts from __core: :scoring: :rms_util__.

Thanks and kind regards,

Nasos

[Anonymous]

I don’t know the answer to 1 – the organization of this code is a mystery to me. It ought to be in AbrelaxApplication.cc somewhere.

As for 2 – no, it does not use a superposition, it uses raw coordinates. This seems silly so it’s probably because it was very tough to do it any other way. The problem is likely to be that the constraints are managed as very abstract – they’re part of the scorefunction and part of the pose, but not a class that you usually interact with directly. I’d guess they couldn’t figure out a good way to pass in the necessary companion data to perform the superposition in a reliable way. (It may have turned out to be too slow as well – performing the superposition every time the constraint is evalulated would be a huge hit).

I believe most users use AtomPairConstraints instead of CoordinateConstraints; these constrain atoms relative to one another and thus don’t need superposition. They may work better in your case? There is also a BindingSite constraint which does something similar but is meant for interfaces.

[Anonymous]

Perhaps I’m using the wrong constraint type altogether. I initially wanted to use __AtomPairConstraints__, but it seems that this only constrains the atoms relative to others within the same pose– is there a way to constrain the atoms in one pose to atoms in another pose?

[Anonymous]

I don’t think any of the constraint scores will track that the way you want – they’re all within one pose. There is an RMSD score term that will globally constrain one pose to look like another, but it’s perhaps too simple for your purpose because it only uses the Calpha trace.

When you use CoordinateConstraints, what are the coordinates of the constraints versus the coordinates of the result? You might be able to transform the coordinates for the constraints into the result space to get this to work the way you want. Rosetta’s abinitio might be refusing to allow the whole protein to translate at once (there’s usually no reason to do this), which would cause problems with CoordinateConstraints if the pose’s area of cartesian space is far from the target. But, you can transform the target to be near where Rosetta wants the result to be and it might work?

[Anonymous]

Smlewis, thanks for your quick responses.

Actually, the C-alpha trace RMSD is what I need. Can I set the RMSD score term for a subset of the C-alphas? I want to constrain only the secondary structure elements.

The coordinates of the constraint are superimposed (best-fit) on the native structure (makes it easier to view the two structures together in VMD), and hence they are far from the Rosetta model. I will try to re-align the constraints to the Rosetta models ex post facto and see if this helps.

[Anonymous]

I’m not sure how to do precisely what you want out of the box. (As I’m sure you’ve guessed, neither constraints nor abrelax are my areas of expertise).

You seem reasonably comfortable with code. You could modify the RMSDscore scoreterm to work on a subset of Ca – the files are core/scoring/methods/RMS_Energy for the score term and core/scoring/rms_util for the rms calculating utility functions. There are several RMS functions that take maps determining which atoms to align and RMSD over.

I think you could get away with what you want with a large set of AtomPairConstraints – write one constraint per hbond in the secondary structure (either over the hbond or over the CA – if the CA’s are close Rosetta is likely to prefer secondary structure to satisfy the polar groups) plus a few extra CA to CA constraints between secondary structures and from one end of each element to its beginning.

[Anonymous]

smlewis,

Thanks many times for your guidance and help– I finally managed a solution based on your suggestions:

^
1. I modified the __RMS_Energy__ constructor to read the option __~np~in::file::native_exclude_res~/np~__ and to convert it into __~np~std::list < core::Size > residue_selection_~/np~__ using __~np~protocols::evaluation::invert_exclude_residues~/np~__

2. I added a few lines to __~np~RMS_Energy::finalize_total_energy~/np~__ to use __~np~residue_selection_~/np~__ as an additional argument to __~np~core::scoring::CA_rmsd~/np~__

3. I created a weights patch file with “rms_energy = 1000”

4. I added ~np~”-abinitio:stageX_patch {weights patch file}”~/np~ in my flags file to apply the RMS energy patch
^

So far, it appears to be working nicely. Thanks again!

Nasos

[Author]

Posts