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?
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 Russel drussel@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 >
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 Russel drussel@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
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 Russel drussel@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 Russel drussel@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 >
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 Russel drussel@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 Russel drussel@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
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
I think we should assume each leave has a radii, because less complex code probably means faster :) in my option, read_pdb should add a radius by default and then if someone want to overwrite the values he can in a update_radii function. On Nov 1, 2010, at 1:06 PM, Javier Velazquez 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
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 >
Yeah, that might be a better way to handle Dina's case than special casing it internally.
On Nov 1, 2010, at 1:06 PM, Javier Velazquez 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
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
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
yes :)
On Mon, Nov 1, 2010 at 2:32 PM, Daniel Russel drussel@gmail.com 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 >
-
Daniel Russel -
Dina Schneidman -
Javier Velazquez -
Keren Lasker