based the function from SplineFunc.cc, it seems different number of columns are required when using AtomPair and SPLINE (see code below). But the documentation only says "replace <filename> with EPR_DISTANCE". This would definite leads to compaint of Rosetta.
void SplineFunc::read_data( std::istream &in)
{
utility::io::izstream potential_file;
// If constraints::epr_distance specified, read in histogram from database
if( basic::options::option[ basic::options::OptionKeys::constraints::epr_distance]() )
{
in >> KB_description_ >> exp_val_ >> weight_ >> bin_size_;
filename_ = basic::database::full_name("scoring/constraints/epr_distance_potential.histogram");
//basic::database::open( potential_file, "scoring/constraints/epr_distance_potential.histogram");
}
// Else, read in potential specified in constraints file
else{
in >> KB_description_ >> filename_ >> exp_val_ >> weight_ >> bin_size_;
//potential_file.open( filename_.c_str());
}
it seems different number of columns are required when using AtomPair and SPLINE
AtomPair and SPLINE are two different things. The first is a constraint type, and the second is a constraint function. Rosetta constraints (restraints) are split into two parts. The first (the constraint type) is what you're measuring, and the second (the constraint function) is how you transform that measurement into an energy value. Each constraint type and function takes its own parameters, and therefore there's a different number of columns depending on what constraint type and functions you're using and combining.
All that clarified, I agree that the SPLINE constraint function is rather messy regarding how it's constructed - particularly on the EPR_DISTANCE/filename distinction. In the past I've stared at it for a fair amount without understanding it. I personally wouldn't attempt to put together a SPLINE usage from scratch - I instead would only attempt to copy an existing example usage, changing the parameters to suit my application.
You are right that AtomPair and SPLINE are totally different things. But that's not what I meant (sorry for my inaccurate expression).
What I meant was, when you specify distance between AtomPair using function type SPLINE,
SPLINE:
histogram_file_path experimental_value weight bin_sizethe constraints are speficied using different formats (differnet columns) if key word EPR_DISTANCE instead of file name is given. Compare:
in >> KB_description_ >> exp_val_ >> weight_ >> bin_size_;
and
in >> KB_description_ >> filename_ >> exp_val_ >> weight_ >> bin_size_;
this will lead to an I/O error if users write their constratins following the doc:
" If using RosettaEPR knowledge-based potential, replace <filename> with EPR_DISTANCE, ..."
So perhaps the first line of code should be revised to the same as the 2nd to avoid an I/O error. I propose it because it is a easy fix to avoid puzzling error message (I/O).
Of course copying and changing existing will not cause the error.