You are here

KofNConstraint used only in the final pose scoring

3 posts / 0 new
Last post
KofNConstraint used only in the final pose scoring
#1

I have been using constraints to model protein structure using the AbinitioRelax protocol. 

As my data is very noisy, it occurred to me that KofNConstraint could be a way to have more success.

However, I noticed that the use of KofNConstraint totally ignore the constraints in both centroid and full atom steps of the MonteCarlo trajectory (as Atom_pair_constraint vanishes from the scoring tables during the folding process) and it is used only to score the model at the end. That is, it seems my constraints are being ignored during the trajectory itself and it does not contribute to the gradient-based sampling.

The ideal would be to ignore k-n constraints that have the large violations but have the same behavior as in the absence of KofNConstraint: being used during the whole folding process.

Any ideas on how to turn on this behavior?

 

Állan

Category: 
Post Situation: 
Sun, 2018-07-08 18:18
allan.ferrari

Which options are you using to specifiy the constraint file?

-constraints::cst_fa_file will only be applied during certain fullatom portions of the run. For constraints during the centroid mode, you'll want to use the -constraints::cst_file option.

The other issue which may be happening is that the energy function that's being used needs to have the relevant constraint terms turned on. KofN constraints don't have a type of themselves, but should use the type of the underlying constraints.

One thing to check is if it's specifically the KofN which is messing things up (unlikely, but worth checking). Just for testing, unwrap your constraints, and see if you're still having the same issues. -- Out of curiosity, what sub constraint type are you using within your KofN constraints?

Fri, 2018-08-03 08:08
rmoretti

Hi Rocco,

-constraints::cst_fa_file will only be applied during certain fullatom portions of the run. For constraints during the centroid mode, you'll want to use the -constraints::cst_file option.

I am aware of this. In my flags file I do use the following options: 

-constraints
  -cst_file cstfile.txt
  -cst_weight 1
  -cst_fa_file cstfile.txt
  -cst_fa_weight 1

For example, with a regular cstfile.txt I get:

Centroid mode:

 Scores                       Weight   Raw Score Wghtd.Score
------------------------------------------------------------
 vdw                          1.000       2.470       2.470
 pair                         1.000     -15.127     -15.127
 atom_pair_constraint         1.000       0.011       0.011
 env                          1.000       4.891       4.891
 hs_pair                      1.000       2.884       2.884
 ss_pair                      0.300     -20.387      -6.116
 sheet                        1.000       6.239       6.239
---------------------------------------------------
 Total weighted score:                       -4.748

By adding KofNConstraint in the first line of my cstfile.txt:

Scores                       Weight   Raw Score Wghtd.Score
------------------------------------------------------------
 vdw                          1.000       3.104       3.104
 pair                         1.000      -9.648      -9.648
 env                          1.000       5.604       5.604
 hs_pair                      1.000      -0.245      -0.245
 ss_pair                      0.300      -4.547      -1.364
 sheet                        1.000       0.343       0.343
---------------------------------------------------
 Total weighted score:                       -2.207

That is, atom_pair_constraint is invisible.

 

The other issue which may be happening is that the energy function that's being used needs to have the relevant constraint terms turned on. KofN constraints don't have a type of themselves, but should use the type of the underlying constraints.

If I got it correctly, this shouldn't be a problem based on what I have shown above, right? The function type is defined subsequentially the KofNConstriant. In the documentation, it says Rosetta should see with the "k" constraints with the lowest energy. I can't read the code, but the effect I see is that the constraints are invisible to the Minimizer and the FragMover. 

For clarity, my cstfile.txt has this format:

AtomPair CB 77 CB 115 FLAT_HARMONIC 12.5 1 12.5
AtomPair CB 99 CB 125 FLAT_HARMONIC 12.5 1 12.5
AtomPair CB 113 CB 115 FLAT_HARMONIC 12.5 1 12.5

(...)

In the presence of KofNContraint, I just add it in the first line:

KofNConstraint 52

AtomPair CB 77 CB 115 FLAT_HARMONIC 12.5 1 12.5
AtomPair CB 99 CB 125 FLAT_HARMONIC 12.5 1 12.5
AtomPair CB 113 CB 115 FLAT_HARMONIC 12.5 1 12.5

(...)

Also, I know KofNContraint is being used  because in the log file I have this line:

Read K of N constraints! K = 50 N = 62

 

One thing to check is if it's specifically the KofN which is messing things up (unlikely, but worth checking). Just for testing, unwrap your constraints, and see if you're still having the same issues. -- Out of curiosity, what sub constraint type are you using within your KofN constraints?

The constraint type does not matter. I have tested with different functions type definitions. Same behavior.

Let me know if I provided enough information.

Állan.

 

Sat, 2018-08-04 00:39
allan.ferrari