[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] fleshing out atom.Hierarchy



On Fri, May 22, 2009 at 2:19 AM, Daniel Russel <> wrote:
> Slight improvement of the proposal:
> - if any of the hierarchy has coordinates, all the leaves must

just one q: what about systems with different granularities; i.e., for
part of a complex one might have (in fact rather often...) reasonable
atomic models for some proteins or domains and not for others. for
example, i sometimes have fragments, which have coordinates, and for
others i can go finer in the tree.
how is that solved?

thanks

frido

> - one must be able to determine which Particle each residue is associated
> with
> - the default "radius" attribute is used to an approximating radius- so the
> radius that best approximates the sub-particles at that level of detail
> - hierarchy particles can have a "bounding radius" attribute which
> represents a bounding sphere. This will be used by the close pairs code and
> other code and is assumed to include all relevant geometry associated with
> the particle (so all geometry in the subtree).
>
>
> On Thu, May 21, 2009 at 10:07 AM, Daniel Russel <> wrote:
>>
>> I suggest that we impose that  in an atom.Hierarchy
>> - if any of the hierarchy has coordinates, all the leaves do (they can be
>> at any level of the hierarchy though)
>> - all residues in each molecule must be either a) explicitly represented
>> as a Residue, b) part of a Domain which is a leaf (which would be expanded
>> to allow non-contiguous sets of residues--or we could split off a new type
>> of decorator for this)
>> - any member of the hierarchy other than an Atom which has coordinates
>> also has a radius. The interpretation is that this radius bounds where
>> members of the (possibly elided) subtree can be.
>>
>> These would ensure several useful properties:
>> 1) it be clear what the highest resolution representation of any hierarchy
>> is
>> 2) one be able to find out where in the hierarchy any residue is located
>> 3) code does not need to look at the most detailed representation to get a
>> rough picture of the structure, it only has to search down the tree (I'm
>> from CS) to find a representation with small enough balls.
>>
>> Comments?
>
>
> _______________________________________________
> IMP-dev mailing list
> 
> 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



www.tomotronic.org