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 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.