adding coordinate constraints

[pbradley]

Hi all,

I am trying to figure out how to add coordinate constraints while doing loop minimization without success so far. I would like to constrain my loop CA atoms to their initial positions but if I add coordinate_constraint to my score function this has no effect as I suspect that I need to add constraints to my Pose object but I am not sure how.

Is this possible to do with PyRosetta?

thanks!

[Anonymous]

Adding constraints to the scorefunction consists of giving the constraint scorefunction term a nonzero weight – the SF is not aware of the actual constraints at that stage.

Adding constraints to a Pose actually makes the Pose aware of its “extra physics”, and the Pose passes these along to the SF at scoring time.

Do you have pose.add_constraint( scoring::constraints::ConstraintCOP cst ) available?

[pbradley]

yup I guessed this was the case from the chainbreak experience

I get this from PyRosetta:


Type: instancemethod
Base Class: <type 'instancemethod'>
String Form: <bound method Pose.add_constraint of <rosetta.core.pose._rosetta_core_pose_000.Pose object at 0xccfaf8>>
Namespace: Interactive
Docstring:
add_constraint( (Pose)arg1, (object)cst) -> object :
adding a constraint is done by cloning the input constraint. A const copy is then returned
C++ signature :
utility::pointer::owning_ptr<core::scoring::constraints::Constraint const> add_constraint(core::pose::Pose {lvalue},utility::pointer::owning_ptr<core::scoring::constraints::Constraint const>)

But I don’t seem to be able to have available Contraint classes but not sure.

[Anonymous]

I don’t know how the C++ gets turned into python, but I think the constraints are “wrapped”. You can see it is namespaced core::scoring::constraints, does that help?

CoordinateConstraint is a valid class name in C++, is there some way to search for that in python…?

[pbradley]

yeah I’m searching using tab completion in iPython and the closest I get is a class called:

CoordinateConstraintKC

If that is any help?

[Anonymous]

I don’t know what the KC means. (I still haven’t gotten around to teaching myself PyRosetta…)

Can you also see AtomPairConstraint and DihedralConstraint in the same location?

What about the Funcs? (The constraint is a descriptor of WHAT should be constrained, the Func is the math of HOW it is constrained – square well, parabola, etc). SquareWellFunc, PeriodicFunc, HarmonicFunc?

I emailed the PyRosetta admin – he’ll know off the top of his head if constraints are wrapped.

[pbradley]

No trace of AtomPairConstraint or DihedralConstraint I’m afraid so perhaps this functionality is not wrapped. Thanks for the help again. It is much appreciated!

[pbradley]

also no Funcs either

[Anonymous]

Have you imported rosetta.core.scoring.constraints namespace? This is where all constraints live. Here how to get iPhython to list them:

In [1]: import rosetta.core.scoring.constraints
In [2]: rosetta.init()
In [3]: rosetta.core.scoring.constraints.
Display all 278 possibilities? (y or n)

[pbradley]

thanks, great – I have found CoordinateConstraint. Sorry for the stupid questions I don’t use Python much

But I am a little confused on how to use it as the initializer asks for two AtomIDs. I would have thought only one AtomID, a coordinate vector and a Func would be necessary unless I’ve misunderstood what this does?

Type: class
Base Class:
String Form:
Namespace: Interactive
File: /home/jmacdona/PyRosetta/PyRosetta-Release1.1-r34968.linux.64Bit/rosetta/core/scoring/constraints/_rosetta_core_scoring_constraints_001.so

Constructor information:
Docstring:
__init__( (object)arg1) -> None :
CoordinateConstraint.hh:44

C++ signature :
void __init__(_object*)

__init__( (object)arg1, (AtomID)a1, (AtomID)fixed_atom_in, (xyzVector)xyz_target_in, (Func)func [, (ScoreType)scotype=rosetta.core.scoring._rosetta_core_scoring_001.ScoreType.coordinate_constraint]) -> None :
c-tor

C++ signature :
void __init__(_object*,core::id::AtomID,core::id::AtomID,numeric::xyzVector,utility::pointer::owning_ptr [,core::scoring::ScoreType=rosetta.core.scoring._rosetta_core_scoring_001.ScoreType.coordinate_constraint])

[Anonymous]

I had to go all the way to the top to get an answer; this answer is with some help from Dr. Leaver-Fay.

If you’ve read the Rosetta3 MIE paper, it’s because CoordinateConstraint is functionally a one-body energy, but we need it to be evaluated as a two-body energy (so it re-evaluates when large chunks of pose move).

The first AtomID is your atom.

The second is meant to be a fixed-in-space virtual residue which is the root of the AtomTree. The root cannot move; thus this atom is always in the same place. Code OUTSIDE the coordinate constraint detects when your atom has moved relative to the virtual root and triggers calculation of the constraint. The CoordinateConstraint itself does not use the second AtomID.

You may be able to get away with using the root atom of your AtomTree as the fixed atom, or you can add one of those virtual root.

There is a utility function for adding the virtual root residue; pose::util::addVirtualResAsRoot. It plays with the fold_tree so you may need to re-check the tree for loop compatibility, or manually build the tree yourself. (I don’t know if it’s wrapped, but it is in 3.2.1 so you can convert the C++ to python yourself?)

[pbradley]

that makes sense and explains the issue. Thanks a lot to you and Andrew. I’ll give this a try.

[Author]

Posts