perfect to me :) On Nov 1, 2010, at 2:32 PM, Daniel Russel wrote:
> So, to make a concrete proposal: > - IMP::atom::Hierarchy now requires all leaves to have radii to be a > valid hierarchy (of course, the hierarchy can be invalid during > construction, it just means that functions which take hierachies are > free to assume all the leaves have radii) > - IMP::atom::read_pdb and IMP::atom::read_mol2 will (in general) add > radii to all atoms > - IMP::atom::read_pdb which have an optional parameter to not add > radii. I'm not sure if this parameter should be documented, perhaps > not initially > - IMP::atom::add_radii will overwrite existing radii, rather than > complain (I'm not sure if it complains now or not, but we will > document that it does not) > > Sounds good to everyone? > > > On Nov 1, 2010, at 1:21 PM, Dina Schneidman wrote: > >> I think parameter is a good idea if we want to have one function. but >> we should indeed have the option to control it. >> >> On Mon, Nov 1, 2010 at 1:06 PM, Javier Velazquez javi@salilab.org >> wrote: >>> How about a parameter add_radii (true/false)? >>> >>> On 10/31/10 4:30 PM, Daniel Russel wrote: >>>> If people are going to have to make a decision about radii or >>>> not, they might as well do it by calling add_radii after >>>> read_pdb. That is more general and avoids doubling the number of >>>> read_pdb functions (and read_mol2 functions). >>>> >>>> But if almost everyone who calls read_pdb call add_radii >>>> afterwards, we might as well save them the trouble of learning >>>> two functions (and avoid the mistake of trying to perform >>>> excluded volume computations with points, which I have done >>>> various times and I have seen others do many times too). If we >>>> added the radii, we could then assume that leaves in the >>>> hierarchy always have radii which would make various code less >>>> complex. >>>> >>>> A perhaps bigger issue is that we don't always know what radii to >>>> add, but I think we can provide a good enough guess for almost >>>> anything. >>>> >>>> On Oct 31, 2010, at 3:19 PM, Dina Schneidman wrote: >>>> >>>>> I think we can simply add additional function: >>>>> read_pdb_and_add_radii >>>>> that will do what the name suggests :) >>>>> >>>>> On Sat, Oct 30, 2010 at 6:45 PM, Daniel >>>>> Russeldrussel@gmail.com wrote: >>>>>> Hmmm, good point. Not sure supporting static executables is >>>>>> something to use to guide interface changes. We could just have >>>>>> read_pdb catch the exception as a hack to deal with incomplete >>>>>> IMP setups. BTW, there is now a function to set set search path >>>>>> for data at run time. >>>>>> >>>>>> >>>>>> On Oct 30, 2010, at 11:12 AM, Dina Schneidman wrote: >>>>>> >>>>>>> In that case any application will require the parameter files >>>>>>> and >>>>>>> handling the paths to them. >>>>>>> I specifically added another way of adding radii to avoid >>>>>>> dealing with >>>>>>> those files (applications/saxs/profile.cpp). >>>>>>> >>>>>>> On Sat, Oct 30, 2010 at 9:31 AM, Daniel >>>>>>> Russeldrussel@gmail.com wrote: >>>>>>>> Given that >>>>>>>> - doing almost anything useful requires adding radii to atoms >>>>>>>> - we currently have only one way to do that >>>>>>>> - it generally doesn't matter what radii we use for atoms for >>>>>>>> most of what we do >>>>>>>> - one can always overwrite the radii with other values if one >>>>>>>> wants other values >>>>>>>> I propose the read_pdb function add radii to the atoms it >>>>>>>> creates. >>>>>>>> >>>>>>>> Comments? >>>>>>>> _______________________________________________ >>>>>>>> IMP-dev mailing list >>>>>>>> IMP-dev@salilab.org >>>>>>>> https://salilab.org/mailman/listinfo/imp-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> IMP-dev mailing list >>>>>>> IMP-dev@salilab.org >>>>>>> https://salilab.org/mailman/listinfo/imp-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> IMP-dev mailing list >>>>>> IMP-dev@salilab.org >>>>>> https://salilab.org/mailman/listinfo/imp-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> IMP-dev mailing list >>>>> IMP-dev@salilab.org >>>>> https://salilab.org/mailman/listinfo/imp-dev >>>> >>>> >>>> _______________________________________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> -- >>> Javier Velazquez >>> Postdoc at Salilab, UCSF >>> 1700 4th st. Byers Hall, office 503. >>> 94158 San Francsico >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev