Just as a clarification, the point is not to have a be all and end all solution, it is to provide a more reasonable starting point and make it clear that there is a scaling issue. In addition, establishing a convention about how the error scales with the number of atoms means that the scaling will have to be changed less after modifications to the representation (local optimization, rather than a global one :-)
The fact that some restraints types (especially ones which are not near a minimum of the restraint at the minimum of the whole function) are difficult isn't really relevant IF some restraints are easy. We can provide functions/guidelines to handle the easy cases serving the dual purpose of automating what can be automated and providing a reminder of what cannot. And, what is easy for us, is not necessarily easy for others. Whether some are easy outside of diameter and excluded volume is still under contention though :-)
On Jun 8, 2009, at 1:29 PM, Friedrich Foerster wrote:
> if you really want to provide a solution making most people happy i'd > suggest learning from x-ray crystallography. there restraints are > commonly scaled by doing a number of optimizations to get an estimate > for the scaling. a similar solution would be greatly appreciated, but > it is considerable amount of work. > > i am pretty sure that any default scaling would by far be insufficient > for most cases, not to speak of 80 %. already ben's example with the > homology-based restraints should make it obvious that a generic > scaling factor is probably impossible to derive in a rather heuristic > framework as imp or modeller.
> > therefore, if you really intend to make a one-fits-all solution i'd > advocate for a serious effort in analogy to established x-ray > protocols. fudge solutions won't buy anything, i predict. e.g., what > about the resolution of em maps. just to name one problem ... > > cheers > > frido > > On Mon, Jun 8, 2009 at 10:10 PM, Ben Webb ben@salilab.org wrote: >> Daniel Russel wrote: >>>> Most physics-based scores are interaction energies between pairs of >>>> particles. But not all of course, otherwise this would be a solved >>>> problem already. >>> Sure, but for what we do (namely, not gravitation), the number of >>> pairs >>> scales linearly with the number of atoms rather than quadratically >>> (since we have terms with finite cutoffs and packing constraints). >> >> That is not true for Modeller-style homology-derived restraints, as >> one >> example. >> >>> Rescaling a physics forcefield is harmless if all you are >>> interesting in >>> doing is preserving minima. >> >> Of course, but rescaling different parts of the forcefield by >> different >> amounts (e.g. bond terms vs. torsions, since the latter act on >> twice as >> many atoms) will really break things, and that was what I read your >> proposal as. >> >>> That said, looking like existing physics >>> force fields is a reasonable criteria. But that requires that the >>> other >>> terms scale with the number of atoms too (since all of the force >>> fields >>> have finite cutoffs). >> >> Molecular mechanics people have worked with such nonbonded >> interactions >> in their forcefields for many years: the effects of such cutoffs on >> the >> energies and dynamics are well understood. I don't think the same >> could >> be said for a rescaled term. This is why I suggest rescaling terms >> such >> as EM and SAXS rather than sterics and nonbonds. >> >> Ben >> -- >> ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> > > > > -- > -- > > Dr. Friedrich Foerster > Max-Planck Institut fuer Biochemie > Am Klopferspitz 18 > D-82152 Martinsried > > Tel: +49 89 8578 2651 > Fax: +49 89 8578 2641 > > foerster@biochem.mpg.de > > www.tomotronic.org > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev