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 <> 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 Russel<> 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<> 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
>>>>>>
>>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>>>
>>>>> _______________________________________________
>>>>> IMP-dev mailing list
>>>>>
>>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> IMP-dev mailing list
>>>>
>>>> https://salilab.org/mailman/listinfo/imp-dev
>>>>
>>>
>>> _______________________________________________
>>> IMP-dev mailing list
>>>
>>> https://salilab.org/mailman/listinfo/imp-dev
>>
>>
>> _______________________________________________
>> IMP-dev mailing list
>>
>> 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
>
> https://salilab.org/mailman/listinfo/imp-dev
>