The reason to hide it is so that the implementers of restraints don't have to remember to scale everything properly, it just happens for free. The idea would be thatI think the three alternatives for weights are 1) Hide it in the restraint class. To make this clean, we should hide the the ModelData* and mirror its functions in the Restraint base class (strictly speaking we only need to mirror add_to_deriv, but for symmetry, we should do all if we do one). For the return value, I would suggest adding a function weighted_eval which is called by the Model or RestraintSet instead of eval and calls eval internally. Then, anyone who wants to override that directly will know they need to deal with the weights themselves. Note that this proposal breaks if we move to a "Particles as Objects" framework since adding to the deriv involves an arbitrary function call.?! i probably need a translation for dummies... making a scaling factor part of a restraint seems logic to me - although i do not fully understand why it should be hidden. scaling is not an evil thing, no reason to be ashamed of it.
- you implement a MyRestraint::evaluate function- the value it returns is weighted properly in the Restraint::weighted_evaluate function which called evaluate - MyRestraint::evaluate adds to the derivative by calling Restraint::add_to_derivative which scales the value appropriately before passing it to the ModelData. In order to make sure that you do this and don't slip up and accidentally call ModelData::add_to_deriv directly, all the ModelData access and set functions that MyRestraint needs are implemented in Restraint and the Restraint::ModelData pointer is declared private.
So the changes from the current system is only that instead of calling Restraint::get_mode_data()->get_float() you leave out the "get_mode_data()->" part (likewise for add_to_deriv). So it would just simplify things.
Me too (to the second part) I think in practice it might be a bit annoying and complicated to implement. I haven't thought this one at too much. I am pretty sure the first one would work out to be simpler in the long run, just would requires some simple changes to Restraints, where as this way would not.2) Keep it external to the restraint. To do this we would give each restraint a separate ModelData which has a weight in it and scales add_to_deriv calls accordingly. The external user would be responsible to for weighting the output. I don't like this as much as 1.1 sounds better to me although again i only grasp a vague idea.
I don't see where I wrote that, so I can't tell you what I meant :-) Anyway, there need be no such assumption.i am not quite sure i understand it. maybe you mean that all restraints are fulfilled in the 'correct' model as frank always reasons.3) Store the weight in the Restraint base and hope the Restraints scale everything themselves. This is pretty easy to write a test that checks if a restraint is doing the right thing and such a test could be put in the model and run on each added restraint if debugging checks are enabled. This is the only approach of the three that will work if we go to particles as objects. We can provide macros that make the code a bit simpler too.