First off, a terminology disclaimer: When Rosetta talks about “constraints”, most of the time it’s really talking about what most other computational approaches call “restraints”. That is to say, Rosetta “constraints” don’t prohibit sampling outside the “constraint”, but instead attach an energy penalty to the “constraint” violation – the lower the penalty the more satisfied the “constraint” is.
As far as Rosetta is concerned, it’s perfectly fine with 300 ambiguous constraints – writing such a constraint file by hand might not be recommended from a tedium point of view, but Rosetta will be fine with reading it in. (If you have the list like you showed above, it should be easy to script a conversion, though.)
AmbiguousConstraints might be what you”re after. To use them, you need to be able to break your constraints into groups where you can say “I either want this constraint to be satisfied, or I want that constraint to be satisfied, whatever gives me a better score”. Each of those groups then gets their own ambiguous constraint.
That might not be what you want, though. I get the sense that you don’t have any subgroupings of constraints, but instead want to satisfy as many of them as possible at the same time. In that case you don’t need to use ambiguous constraints – you can just apply all the constraints plain. Rosetta will attempt to maximize the number of constraints it satisfies, and will simply accumulate the energy penalty for the ones it can’t. If you set up the associated functions appropriately, the constraints you want will be the ones favored.
For your situation, I’d recommend using an AtomPairConstraint to constrain distances, and then using the BOUNDED function. You can set the lower bound to 0 and the upper bound to 25 to have the constraint be zero in the range of 0 to 25 angstroms. You can then adjust the sd value such that the ones with the most preference get the greatest sd value, making them the ones Rosetta tries to optimize the most.
This might not quite get you where you want to go, though. In this scheme if you can’t make a constraint, you’ll do your best to move the structure as close as possible to where you could satisfy it. This may compress the protein unnecessarily. There’s a couple of approaches to get around this. If you have a sense about what fraction of the constraints will likely be invalid, you can wrap everything in a single KofNConstraint. That’s like an AmbiguousConstraint, but will allow you to specify that you want the top 250 or 170 of your 300 constraints to be evaluated, and the worst 50 or 130 to be ignored. The other possibility is to do what the Ambiguous constraint example is doing. You set up a bounded constraint with the main penalty, and then you add a CONSTANTFUNC or a LINEAR_PENALTY function to cap how severe the penalty gets (and how steep the slope), minimizing the effect you get for violating the constraint.
.
