You are here

KofNConstraint used only in the final pose scoring

6 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

Hi,

I have tried some things that may be halfway to solve my problem.

1) I realize that it needed to add the -score:set_weights atom_pair_constraint 1.0 flag if I want to use KofNConstraints. 

I was surprised because in the absence of KofNConstraints I wouldn't need this flag. Only using: -constraints:cst_file {cst_file} -constraints:cst_weight 1  -constraints:cst_fa_file {cst_file} -constraints:cst_fa_weight 1 

2) I wanted to verify if the distribution of models I obtained by using, let's say 62 constraints would be the same as using KofN 62 (62 lowest energy constraints out of 60 constraints). What I saw is that in the absence of KofNConstraints my constraints energy were shifted to more negative values compared to the one I use KofNConstraints.

I look to both log files and I found the following difference:

- run without KofNConstraints

core.scoring.constraints.ConstraintsIO:  read constraints from xl
core.scoring.constraints.ConstraintsIO: Read in 62 constraints

- run with KofNConstraints

core.scoring.constraints.ConstraintsIO: read constraints from xl
core.scoring.constraints.KofNConstraint: Read K of N constraints! K = 62 N = 62
core.scoring.constraints.ConstraintsIO: Read in 1 constraints


Now, I wonder why ConstraintsIO just read 1 constraint. This may help to explain why my constraints energy is higher with KofNConstraints.

Someone could help me fixing this?

I dumped the input files here (https://1drv.ms/f/s!AqJBrTd9Fp4IozUkwaFpB-9XQRTO) that I use for both runs: XLFF_noKofN folder (which contains the run without KofN) and XLFF_KofN folder (which contains the run with KofNConstraints). You will find also a rosetta.log file which may be helpful if you don't want to run it again. If you opt to run it, you will need either to change the function that defines each constraint or to copy these files (https://github.com/mcubeg/xlff/tree/master/Rosetta) to Rosetta and recompile to run the ETABLE function properly.

 

Mon, 2018-09-24 21:11
allan.ferrari

One more thing to add.

You will notice that using KofNConstraints also get rids of protocols.abinitio.foldconstraints in the ab initio protocol (which is particularly important!)

Tue, 2018-09-25 17:08
allan.ferrari

Ok. After trying to read the what was going on at ConstraintsIO.cc and putting some prints to track what was happening, I can tell that the constraints are not being read in the scope of ConstraintIO.cc when I use KofNConstraints.

At line 509 of the code (cst_op = read_individual_constraint_new ...) in the absence of KofNConstraint it reads each of the AtomPair constraints and it enters the if condition to add to the cset the new constraint. In the presence of KofNConstraint, however, only then the constraint file is read it goes to the if condition. The file ends with an END which means no constraint is added to the cset. As a result the log file present the tr.Info "Read in 1 constraints". But, in fact it returns cset 0. Also, because cset = 0 the Abinitio runs without constraints in the ClassicAbinitio mode instead of FoldConstraints mode. 

     while ( data.good() ) { // check if we reach the end of file or not
            // read in each constraint and add it constraint_set
            ConstraintOP cst_op;
            cst_op  = read_individual_constraint_new( data, pose, get_func_factory(), force_pdb_info_mapping );
            if ( cst_op ) {
                  ++count_constraints;
                  cset->add_constraint( cst_op );
            } else if ( ! data.eof() ) { // not end of line
                  tr.Error << "reading constraints from file" << std::endl;
                  using namespace basic::options;
                  using namespace basic::options::OptionKeys;
                  if ( option[ OptionKeys::constraints::exit_on_bad_read ]() ) {
                        utility_exit_with_message( "ERROR: reading constraints from file"  );
                  }
                  break;
            }
      } // while
      tr.Info << "Read in " << count_constraints << " constraints" << std::endl;
      return cset;

 

I tried to do something to the code. But, without c++ experience, that is all I could get so far. 

 

 

 

Thu, 2018-09-27 21:49
allan.ferrari