a trouble during floppytail modeling

[Anonymous]

Hello,
I am using FloppyTail in Rosetta 3.2. After the first stage, the centroid modelling, there was really an expected folding in my designated tail region. However, my problem was that the protein containing floppy tail dissociated from original protein complex significantly, but the other components were still well organized as previous. Also, the second stage, fullatom modeling, could not correct it. How could I deal with it?
I thought those input start and stop residues positions were right, fragment file was also provided.

Thanks very much.

[Anonymous]

I’m not immediately clear on what your problem is. If you post the PDB and the options you used I’ll take a look at it.

I’m guessing there’s an issue with the fold tree. Try re-organizing the components of your complex in the PDB such that protein with the flexible tail is the last one in the PDB file. You don’t need to change the coordinates and probably not the numbering/chains – just make sure the flexible one is last. Let me know if this fixes it so I can update the documentation.

[Anonymous]

Yeah, it was written for a flexible C-terminus, and all the cases I can think of it’s been used on a C-terminus or an internal residue. I thought it had code to detect an N-terminal tail but maybe it doesn’t. I’ll take a look tomorrow.

[Anonymous]

OK, I looked into it a little deeper. FloppyTail will automatically detect N-terminal tails and attempt to handle them properly. The N-terminal handling comes at two costs:

A) The N-terminal tail has to be the FIRST part of the PDB (this is opposite from the suggestion I had before; C-terminal tails work best last). I tried this briefly and it worked okay

There may be a significant performance hit for an N-terminal tail as compared to a C-terminal tail of equal length. You may be able to fix this by playing with the FoldTree. Refer to the 2011 Leaver-Fay Rosetta3 paper, and the 2007 Wang/Bradley/Baker paper on docking with backbone flexibility, to understand what the FoldTree is. N-terminal tails may be slower because if the FoldTree root is in the tail, all parts of the complex will move as the tail moves; updating the 3d coordinates will get expensive.

If you see a performance hit, you can try fiddling with the code inside this block (starting at line 232 or so of src/apps/public/scenarios/FloppyTail.cc)


//for nonterminal sections, this fold tree might help (or might make it worse...)
if( stop_ != pose.total_residue() ){
TR << "non-terminal floppy section, using a linear fold tree to try to ensure downstream residues follown"
<< "Old tree: " << pose.fold_tree();
pose.fold_tree(core::kinematics::linearize_fold_tree(pose.fold_tree()));
TR << pose.fold_tree();
}


You may be able to restore performance if, after the line that says linearize_fold_tree, you add a line:


pose.fold_tree(pose.fold_tree().reorder(pose.total_residue());


I haven’t tested it but it has a fair chance of helping. Let me know if it works and I’ll patch it for the next release.

[Anonymous]

“So if possible and at your conveinence, could you share with us your method to change pdb chain id?”

I meant to move the lines of text in the PDB around, not re-letter the chains. The order in which the domains appear in the PDB file is relevant; their chain IDs are not. (That the chain ID matches what you pass to -flexible_chain does matter, of course). To answer the question you asked, the easiest way is sed, awk, or a basic text editor like emacs or vim. There are many tutorials floating around the internet on “regular expressions”, which is how you’d do the regular-expression search-and-replace to change the chains.

As for the patched code – I tested that it compiles this time (against developer trunk, not 3.2, but it should be ok). I tried to get fancy and do all the changes on one line, but the compiler reminds me I have to make a local copy of the FoldTree to modify it. Here’s code that will compile; let me know if it works:


//for nonterminal sections, this fold tree might help (or might make it worse...)
if( stop_ != pose.total_residue() ){
TR << "non-terminal floppy section, using a linear fold tree to try to ensure downstream residues follown"
<< "Old tree: " << pose.fold_tree();
pose.fold_tree(core::kinematics::linearize_fold_tree(pose.fold_tree()));
core::kinematics::FoldTree ft(pose.fold_tree());
ft.reorder(pose.total_residue());
pose.fold_tree(ft);
TR << pose.fold_tree();
}


[Anonymous]

I’ve made some posts on these boards about constraints before:

http://www.rosettacommons.org/node/2313

The documentation is pretty good:

http://www.rosettacommons.org/manuals/archive/rosetta3.2_user_guide/constraint_file.html

In FloppyTail, use a constraint file as described in that last link, with the cst_file and cst_weight options. Note that FloppyTail only applies constraints in centroid mode, so you have to use constraints between backbone atoms (or the centroid atoms, if you care to look them up).

If you’ve read that documentation and still have questions, feel free to ask them.

[Anonymous]

I understand your question now.

I don’t think it’s possible to specify BindingSite constraints via the constraint file; you’d have to write C++ code into FloppyTail to generate the constraint from the coordinates of some “reference state” where the binding was as you wish it to be.

You can use multiple AtomPair constraints to get essentially the same effect. You can also use AmbiguousConstraint or MultiConstraint to combine groups of other constraints to get effects like “this residue needs to hydrogen bond to any of these three partners, but it doesn’t matter which one” or “this quartet of residues has to form this particular geometry”.

I’ve attached an example of a file defining one complex AmbiguousConstraint, since the documentation on it is a little vague. I believe it is compatible with the FloppyTail demo (it was two years ago, but it may have drifted since then).

[Anonymous]

I’ve never tried RMSD with FloppyTail. FloppyTail does not directly support it (it does not take in:file:native as you tried).

You tried the right thing: using the score app to get RMSDs. Try it with the Rosetta 3.1 score.cc, since the score_jd2 in Rosetta3.2 won’t work. Once you have those RMSDs you should be set. (You can install 3.1 and 3.2 on one computer; they won’t “know about” each other and won’t conflict. You may need two copies of the database. I have about 10 Rosetta installations on my computer…)

[Anonymous]

Binding energy is calculated in the function “create_extra_output” at the top of FloppyTail.cc. You may recall commenting out a function call to use FloppyTail, because some of its code is hard-coded for the original system in the Cell paper. That is the code you have to comment out, but it is also the code that calculated the binding energy you want.

If you know any C++, feel free to rewrite the contents of that function so that it applies to your system. That is how it was intended to be used. I forget what your model looks like, but basically you can create Poses from the pieces of the interaction you want and score them; then to get binding energy just subtract the total scores of the two halves of the interface from the total score of the complex: AB – A – B = AB binding energy.

By the time 3.3 rolls around, InterfaceAnalyzer will be released, which does a lot of stuff like this in a much simpler fashion.

[Anonymous]

Thanks for your immediate reply.
It was a great favor for me again, and generally I can tackle this problem from your advice.
1) A little patch question was: in your original code, when calculating E3 energy, you wrote
`core::pose::Pose E3_RING(pose);
E3_RING.conformation().delete_residue_range_slow(E2_start, E3_RING.total_residue());
core::Real const E3_RING_score((*score_fxn)(E3_RING));`

So my little query is that whether E2_start is intentively designed for C-ter, and if I mean to apply it to N-ter, it would be required to substitute both ###_start for ###_stop in this portion and its upper (core::Size const E2_start(pose.conformation().chain_begin(E2_chain)) ###_start for ###_stop.
(Surely, I have accommadated original one to my case, and they are just examples to illustrate my query)

2) another one is about the fragment file.
Would you mind telling me the fragment file used in your case was covering the total full-length, or narrowed to the `tail` part only?
I have checked related papers on fragment, but actually did not come to a clear conclusion. Is this difference quite important? My sense was it would cause little distinction on tiny local structure in few cases.

Thanks!

[Anonymous]

1) All you have to do is ensure that the two sides of your interface end up in different sub-Poses (the ones called E2 and E3_RING in the original code). It will work equally well no matter which of those two the flexible tail ends up in. The fact that your tail is N-terminal makes no difference.

I suggest un-commenting-out (commenting-in?) these lines:
//JobDistributor::get_instance()->job_outputter()->other_pose( job_me, E2, “E2”);
//JobDistributor::get_instance()->job_outputter()->other_pose( job_me, E3_RING, “E3_RING”);
These will print copies of the sub-poses to PDBs with the appropriate names to let you test if the split occurred the way you wanted it to. Once it works you can take these two lines out again.

2) FloppyTail uses only 3-mer fragments. It takes whole-pose fragments, such as those generated by the Robetta server (http://robetta.bakerlab.org/fragmentsubmit.jsp). (The vast majority of the fragment file is never used, which is kind of wasteful. Rosetta’s fragment machinery implicitly assumes you are doing abinitio, whole-structure folding so it forces you to supply a full fragments file.)

I found fragments to be unimportant for the Cell paper, but it might matter if your tail is expected to have significant secondary structure. I can’t tell you if it will matter or not; you’ll have to try it both ways.

[Anonymous]

For future reference, the N-terminal tail efficiency patch I mentioned has been committed to the codebase and should release with 3.3.

[Anonymous]

I have another updated question now, sorry!!

I applied resfile flag in backrub, and it ran OK.
But why did it go to deadlock in floppytail? I really used the same structure and resfile…
It was displayed
`
can not find a residue type that matches the residue CA at position xxx

ERROR: switch_to_residue_type_set fails

ERROR:: Exit from: src/core/chemical/util.cc line: 645
`
Thanks very much for your patience and help.

[Anonymous]

FloppyTail has a centroid phase, it is crashing because it can’t find a centroid residue type for the CA atom.

If FloppyTail will not be remodeling the area with the calciums, then just delete them and don’t worry about it. Rosetta’s scorefunction isn’t going to handle the calciums well anyway. (I wouldn’t trust Rosetta to do it right, but I’m happy to explain how to give it a shot.)

If it IS going to try to remodel that region, you’ll have to hack together a calcium centroid residue type, or add code to re-place the calciums after the centroid phase ends. If you want to add a calcium residue type, try this (these instructions are approximate, I’ve never done it):

1)look in rosetta_database/chemical/residue_type_sets/fa_standard/residue_types
2)find calcium, and copy it to chemical/residue_type_sets/centroid/residue_types; also add it to centroid/residues.txt
3)find the calcium atom specification in chemical/atom_type_sets/fa_standard/???, and copy it to chemical/atom_type_sets/centroid/???, modifying it as necessary to match the other centroid atom types.

[Anonymous]

Thanks very much!

It seemed I`ve handled this trouble following your great suggestions. One thing required to confirm was whether the donor or acceptor in atom_properties file meant donor or acceptor of electrons?

Actually, in my case, although Ca ions were not included in floppytail region, it served to stablized an acid region. Based on my previous practical running of FloppyTail, if there was no Ca ion, basic parts of floppytail models with lowest energies would fall into that region. So I wonder whether there could other possible conformations, except for hanging around that acid region. Also, I checked the supplement information of your Cell paper, and it said models would be evaluated by scorefunction which took into account electrostatics and other energies in centriod phase.

So you meant scorefunction could not treat positive charges of Ca well ?

[Anonymous]

To rmoretti:

I really appreciated you could share your experience with me, and I will try both of them to see which one is better for my case.

But before that, may I ask several questions? Thanks.

1)how could you determine the weight and ensure it could match your model?

2) Starting from lines 246, in file hackelec.cc, it wrote:

`
for ( Size ii = 1; ii <= pose.total_residue(); ++ii ) {
// Do not compute energy for virtual residues.
if ( pose.residue(ii).aa() == core::chemical::aa_vrt) continue;
//iwd Temporary hack: also skip ligand residues
//if ( !pose.residue(ii).is_polymer() )
// continue;

// something of a hack: create a residue set, put inside it a single residue,
// and then use the existing trie creation code — single residue tries are
// constructed with the same logic as are multiple-residue tries.
`
So has the energy calculation for virtual residues been exepmted from hackelec yet ? (ligand residues ?)I am not sure, just to inquire.
And also, in order to activate it to consider my Ca, whether

`//if ( !pose.residue(ii).is_polymer() )
// continue;`

should be also comment on ?

Thanks very much!!

[Anonymous]

Hello,

Sorry for my absence recently, because my computer was damaged and all of my data passed away but now it is Ok again.

Now I would like to update my practice on score weights. I tried 0 0.25 0.5, and turned off calculating hack_elec of protein-protein. It seemed 0.25 was better to match known NMR result.

But actually I am not sure about essential rules of hack_elec calculation. Is there any paper about it?

[Anonymous]

Hi, everyone

Now I would like to extend this floppytail method to simulate the possible conformation transition caused by two mutants on the flexible tail region.

Is it feasible?

Practically, I have gotten over 5000 trajectories so far and there seemed to be some differences between wild type and mutant one. So I want to confirm its feasibility before accumulating more trajectories.

Thanks in advance for any comments.

[Anonymous]

Thanks a lot for your reply.

I tried again following your suggestion, to put my interest component as the last one. But there was no improvement.

the options were’
-in:file:s xxx.pdb
-packing:ex1
-packing:ex2
-packing:use_input_sc
-run:min_type dfpmin_armijo_nonmonotone
-in:file:frag3 aaxxxx03_05.200_v1_3
-flexible_chain F
-flexible_start_resnum 1
-flexible_stop_resnum 44
-AnchoredDesign:perturb_show
-AnchoredDesign:perturb_temp 0.8
-AnchoredDesign:refine_temp 0.8
-AnchoredDesign:refine_repack_cycles 10
-AnchoredDesign:perturb_cycles 500
-AnchoredDesign:refine_cycles 100
-nstruct 1′

One difference is that my ‘floppy tail’ is localized in N-terminal. Could it be the possible reason? Thanks for any further suggestion.

[Anonymous]

Thanks very much for your suggestions.

As for the first advice, I got a nice result finally, but the software I used to correct the PDB chain id was ResDe05, althought it could change the id code, e.g from F to A, my intrested component including “floppy head” still dissociated from others. And then, I took advantage of quick relax function of Rosetta to trim my crude structure complex, and it became okey. So if possible and at your conveinence, could you share with us your method to change pdb chain id?

As for your second great advice, I tried it several times. However, I failed.
It was shown as follows’

src/apps/public/scenarios/FloppyTail.cc: In member function `virtual void FloppyTailMover::apply(core::pose::Pose&)’:
src/apps/public/scenarios/FloppyTail.cc:194: error: no matching function for call to `core::kinematics::FoldTree::reorder(platform::Size) const’
src/core/kinematics/FoldTree.hh:269: note: candidates are: bool core::kinematics::FoldTree::reorder(int)
scons: *** [build/src/release/linux/2.6/32/x86/gcc/apps/public/scenarios/FloppyTail.o] Error 1
scons: building terminated because of errors.

and then I altered your supposed codes into “pose.fold_tree(bool core::kinematics::FoldTree::reorder(int(pose.total_residue())));”

while I came across another unexpected error
“src/apps/public/scenarios/FloppyTail.cc: In member function `virtual void FloppyTailMover::apply(core::pose::Pose&)’:
src/apps/public/scenarios/FloppyTail.cc:196: error: expected primary-expression before “bool”
scons: *** [build/src/release/linux/2.6/32/x86/gcc/apps/public/scenarios/FloppyTail.o] Error 1
scons: building terminated because of errors.”

I was not quite familiar with these source codes involved in fold tree and totally new to linux.
So could you give a little more updated information? If it could not be handled now, I would adopt your first advice. Anyway, I really appreciate your help.

Thanks very much.

[Anonymous]

Thanks a lot.

From your great suggestions, I could go through this knotty obstacle now.

If possible, would you mind giving me some advice on my last question, about how to add binding site constraint function, especially the constraint definition. Could it be self-made or must be given special formats?

Thank you.

[Anonymous]

Thank you. I think I have already read all these files. Maybe my last question was quite vague.

My question was about binding site constraint, that was not pre-equipped now, as mentioned in the constraint file instruction.(The applicable function was to atom, angle and dihedral) The atom constraint was not equal to binding site constraint, I think, because we could not define certain residue on designated chain. For example, sometimes different chain may have identical residue number, so that besides residue number, chain id was also required to specify in the constraint file. So I wonder how I could make an applicable binding site constraint file. I have checked the constraintfactory.cc, and binding site function was really unactivated.

Thanks a lot.

[Anonymous]

Thanks very much.
It was a great constraint setting instead of binding site, I think. I will try it later.
An additional question was about how I could construct a rmsd verse energy score plot to evaluate these abundant candidate structures, as docking does(complex with lowest energy was set to input)? Is it feasible for floppytail?
Initially, I would like to just copy the procedures in prepack options of Rosettadocking. However, I saw that there was no native structure input option. I also tried score_jd2.linuxgccrelease, but a hint said that no weight file was rendered.

If possible, could you give me any hint? Thanks a lot.

[Anonymous]

I have the exact same question, but I couldn’t find the attached example.

I’d appreciate if you can share it again, although it’s been so long since then!

[Anonymous]

I have the exact same question, but I couldn’t find the attached example.

I’d appreciate if you can share it again, although it’s been so long since then!

[Anonymous]

I have the exact same question, but I couldn’t find the attached example.

I’d appreciate if you can share it again, although it’s been so long since then!

[Anonymous]

Thanks for your patient instruction on rosetta!!

[Anonymous]

Excuse me, I have an updating problem on evaluating the results.
In your that published Cell paper, I saw you sorted these candidate models by measuring their binding energy. However, this function seemed to be restricted to docking part, so whether you built and picked out optimized model mainly by ab initio and docking simulation, and then by floppytail only for confirmation. If not, could you share with us how you calculated the binding energy as well as their respective monomers’ energy in the complex?
If I missed some obvious flags to achieve it, please forgive me.

Thanks very much.

[Anonymous]

Thanks for rosetta’s generous sharing and great help to us!!! Waiting for 3.3 release!!

[Anonymous]

A) Donor and acceptor refer to hydrogen bond donation and accepting. For example, backbone carbonyl is an acceptor, N-H is a donor. (unless I have that backwards…)

The electrostatics term in most of Rosetta, including FloppyTail, is the fa_pair term. I believe it is explained in the 2004 Rohl paper. Briefly, it was parameterized by examining the distribution of charged residues in a large database of structures. Charged residues in your structure are then graded based on how similar their distribution was to the reference distribution. For example, in the reference, it was uncommon to see two arginines near each other, so there is a penalty. It is common to see a glutamate and an arginine near each other, so there is a bonus. This handles electrostatic attraction/repulsion for the 20 canonical amino acids very efficiently, but as you can see has no idea what to do with calcium, as calcium wasn’t parameterized. There are score function terms available for “proper” coulombic, etc, electrostatics, but I’ve never used them, and I don’t know if they handle ions well. You can try looking at the code for hack_elec?

[Anonymous]

Thanks for your clear explanation.

I think I would be excited to try hack_elec calculation part, but could you tell me how to awake this function, because there was not hack_elec in my score file.

[Anonymous]

code is in src/core/scoring/hackelec/*

You activate it by giving a weight to “hack_elec”. I don’t know what weight to use; ideally one uses a whole other protocol (not released yet) to re-fit weights as the scorefunction changes.

If you look at FloppyTail.cc, line 171 or so:

//set up fullatom scorefunction
fullatom_scorefunction_ = ScoreFunctionFactory::create_score_function( STANDARD_WTS, SCORE12_PATCH );
if( pair_off ) fullatom_scorefunction_->set_weight( fa_pair, 0.0 ); //not for general use
TR << "Using fullatom scorefunction (STANDARD_WTS, SCORE12_PATCH), pair may be modifiedn"
<< *fullatom_scorefunction_;

after the if( pair_off) line, add a line:
fullatom_scorefunction->set_weight( hack_elec, PICK_A_WEIGHT );
and it should activate hack_elec. (of course put in a number for PICK_A_WEIGHT.)

Your logfile should start reporting hack_elec is on, just after the line “Using fullatom scorefunction…”.

[Anonymous]

Thank you very much.
And I will try it immediately.

But now I still want to propose another question. In my case, I found that binding energy and total score were not always consistent with each other. Sometimes, model with lowest binding energy owned quite high total score. So I think maybe there could be a situation that although the complex model with high propensity to reach to the low binding energy model, it was just a transient binding and unstable, concerning the high score(i.e.high total energy). So I think maybe comparing total energy and binding energy together would be better.
Maybe in your case, they had the same trend? How did you treat them?

Thanks!! Thanks!!

[Anonymous]

For enzyme design we typically use a hack_elec weight of 0.25, but we also typically turn on exclude_protein_protein_hack_elec in the EnergyMethodOptions object {e.g. sfxn->energy_method_options().exclude_protein_protein_hack_elec(true)} so that we only include the electrostatics to the non-protein residues – protein-protein interactions are still covered by fa_pair. Some of the protein-DNA interaction people have been getting good results by turning off the fa_pair term entirely, and then setting hack_elec to about 0.5 or so.

[Anonymous]

I forget the details; if I remember correctly we had a large pool of structures that were roughly isoenergetic in total energy, so we used binding energy as a second ranking metric. It is often appropriate to combine many methods of ranking; the best way to do it will vary from system to system.

Rosetta’s Monte Carlo chooses models based only on TOTAL energy, and has no conception of binding energy – so binding energy is more of a filter than part of the experiment directly.

[Anonymous]

1) To turn on hack_elec, you should include a line for hack_elec in your weights file. Normally what I do is copy minirosetta_database/scoring/weights/score12_full.wts (or whatever starting weights file you want) to the local directory and then add in a line for hack_elec setting it to the value that I want. You would then just use the “-score:weights ” command line option to specify the weights file you want to use. (You have to be a little careful, as not all programs use the -score:weights flag, in which case you’d have to find out the ones they do use, or in a pinch, you could just edit the files in the database itself.)

As far as which value you should use, that’s a little bit more tricky. Ideally you’d have a test set of similar runs with known solutions, and then you’d find the value of hack_elec which would give you the best results on the test set. That’s probably overkill for you. So what I’d recommend is to do several runs of your protocol with varying hack_elec weights (I’d probably start with values in the 0.25 to 0.5 range), and see how the different values affect the results. If the results don’t vary much, the weight is not that critical. If the results vary, you’ll need to use your scientific intuition to determine which values give the more realistic results.

2) The if ( …. ) continue lines are there to prevent wasting time on the calculation of the hack_elec term for certain residues. Virtual residues don’t have any real atoms, so they shouldn’t have any columbic energy associated with them – we can skip them. On the other hand, polymeric residues (like protein amino acids) do have real atoms, and so should be included in the calculation of the energy. The exclude_protein_protein_hack_elec-dependent exclusion happens elsewhere in the code.

Your calcium residue is neither a virtual residue nor a polymeric one, so none of the checks you posted would matter for it.

[Anonymous]

sorry for replying so late.

I think your explanation was quite nice. I could enjoy it!! you are really as informative as smlewis and renfrew.
Surely, I would try several weights and post preferencial weight in my case.

Thanks!!

[Anonymous]

I’m not aware of any paper which specifically addresses the hack_elec calculation. You can examine the details of the implementation in src/core/scoring/hackelec/*, if you know a bit of C++.

Basically, it’s a standard Coulombic electrostatic term, but with a distance-dependent dielectric (10r), which makes it so that the interaction drops off rapidly enough that a 5.5 Ang atom-atom cutoff can be imposed. (The potential is also shifted such that there is a smooth transition to 0 energy at 5.5 Ang.) There’s also a close-distance cutoff of 1.5 Ang, so that all atom-atom pairs closer than 1.5 Ang are locked at the 1.5 Ang values, to avoid unrealistically favorable interactions.

I’m uncertain as to how the partial charges for each atom were derived. You can see them in the params file in rosetta_database/chemical/residue_type_sets/fa_standard/residue_types/l-caa/ (or similar directories for non-amino acid residues). If I had to guess, I would surmise they started with CHARMM-type charges, but I don’t know if they’ve been tweaked or adjusted since then. For ligand binding or enzyme design, people frequently use AM1-BCC partial charges (as calculated by OpenEye Omega) for parametrizing non-protein ligands, though I’m not sure how extensively different partial charge sets have been verified.

[Anonymous]

Amazing explanation!!! It`s much more than what I`ve expected…

Thanks very much.

[Anonymous]

I think you’re asking, “can I make mutants and run FT trajectories to see if Rosetta predicts different conformations?” Sure, go for it. I can’t guarantee Rosetta will do it right, but it’s a very reasonable question to ask.

If you are using fragments, and the mutations are in flexible regions, you should regenerate fragments for the new sequence.

[Anonymous]

Thanks very much.

That’s what I am doing now.

[Anonymous]

Without digging through this entire thread all over again, here is a simple AmbiguousConstraint case that constrains such that one residue of region 1, and one residue of region 2, are close to some target residue:

 

#target residue is 45

#region 1: 131-140

#region 2: 158-162

 

#########region 1 vs 45 ########

AmbiguousConstraint

AtomPair CA 45 CA 131 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 132 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 133 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 134 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 135 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 136 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 137 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 138 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 139 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 140 BOUNDED 0 8 1 0.5 bstag

END

#######END#########cdrh1 vs 45 ########

 

 

######### region 2 vs 45 ########

AmbiguousConstraint

AtomPair CA 45 CA 158 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 159 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 160 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 161 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 162 BOUNDED 0 8 1 0.5 bstag

END

#######END#########cdrh2 vs 45 ########

 

Separately, let me note that SiteConstraint does appear compatible with constraint files (now).  The syntax is “SiteConstraint atomname residuenumber targetchain func”.

[Anonymous]

Without digging through this entire thread all over again, here is a simple AmbiguousConstraint case that constrains such that one residue of region 1, and one residue of region 2, are close to some target residue:

 

#target residue is 45

#region 1: 131-140

#region 2: 158-162

 

#########region 1 vs 45 ########

AmbiguousConstraint

AtomPair CA 45 CA 131 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 132 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 133 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 134 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 135 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 136 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 137 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 138 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 139 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 140 BOUNDED 0 8 1 0.5 bstag

END

#######END#########cdrh1 vs 45 ########

 

 

######### region 2 vs 45 ########

AmbiguousConstraint

AtomPair CA 45 CA 158 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 159 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 160 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 161 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 162 BOUNDED 0 8 1 0.5 bstag

END

#######END#########cdrh2 vs 45 ########

 

Separately, let me note that SiteConstraint does appear compatible with constraint files (now).  The syntax is “SiteConstraint atomname residuenumber targetchain func”.

[Anonymous]

Without digging through this entire thread all over again, here is a simple AmbiguousConstraint case that constrains such that one residue of region 1, and one residue of region 2, are close to some target residue:

 

#target residue is 45

#region 1: 131-140

#region 2: 158-162

 

#########region 1 vs 45 ########

AmbiguousConstraint

AtomPair CA 45 CA 131 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 132 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 133 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 134 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 135 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 136 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 137 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 138 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 139 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 140 BOUNDED 0 8 1 0.5 bstag

END

#######END#########cdrh1 vs 45 ########

 

 

######### region 2 vs 45 ########

AmbiguousConstraint

AtomPair CA 45 CA 158 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 159 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 160 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 161 BOUNDED 0 8 1 0.5 bstag

AtomPair CA 45 CA 162 BOUNDED 0 8 1 0.5 bstag

END

#######END#########cdrh2 vs 45 ########

 

Separately, let me note that SiteConstraint does appear compatible with constraint files (now).  The syntax is “SiteConstraint atomname residuenumber targetchain func”.

[Author]

Posts