thanks.

currently, i do not use the top hierarchy layer. personally, i find it cumbersome to tie everything to a hierarchy on the representation level. every time i want to incorporate a new type of experimental data, i discover that it requires a new hierarchy level, which i haven't imagined before. but changing the representation hierarchy always involves so many changes so that i try to keep away from tying the restraints to a fixed hierarchy. for example, in this case i might discover that i require a sub-complex and a sub-sub-complex hierarchy level and so forth. thus, i'd appreciate some way of incorporating such a restraint without a fixed representation hierarchy, which i would need to fix constantly... any other opinions?

thanks

frido

On Dec 18, 2008, at 2:59 PM, Daniel Russel wrote:

> See the "connectivity restraint" example (under simple examples) to > get started. To replicate Frank's restraint you need another layer > of conditionality which can be done by chaining the > LowerRefinedPairScores something like > > ps= IMP.core.SphereDistancePairScore(IMP.core.HarmonicUpperBound(0,1)) > cps= IMP.core.ChildrenParticleRefiner() > # find the closest pair connecting two instances of two proteins > ilrps = IMP.misc.LowestRefinedPairScore(cps,ps) > # find the closest instances of two proteins > lrps = IMP.misc.LowestRefinedPairScore(cps,lrps) > cr = IMP.core.ConnectivityRestraint(lrps) > cr.set_particles(hs) > m.add_restraint(cr) > > and ensuring that your molecular hierarchy looks like > - all proteins of type a > - first protein of type a > - leaf representations of first protein of type a > ... > - second protein of type a > ... > - third protein of type a > ... > - all proteins of type b > - first protein of type b > ... > - all proteins of type c > ... > > And putting the "all proteins of type x" particles in the > ConnectivityRestraint. > > If such a hierarchy organization is problematic than we should talk > some more. At the moment there is a shortage of other > ParticleRefiners so you have little choice on your organization > scheme. I have a table based particle refiner somewhere (so you > could replace the first level of ChildrenParticleRefiner with a non- > MolecularHierarchy based approach), but it never got committed > during the reorg. > > The other thing to be aware of is that, if you are using a > derivative-based optimizer, the evaluation is not very efficient (in > that the closest pair is found twice). Let me know if it becomes too > slow and I'll put some effort into figuring out a way to avoid this > problem. > > Does this all make sense? > > > On Dec 18, 2008, at 12:14 AM, Friedrich Foerster wrote: > >> hi there, >> >> is there any example for generating ambiguous restraints in imp? >> i want to deal with a 'frank classic': multiple copies of a >> specific protein exist in an assembly and only one instance >> interacts with another protein (the one that is closer to its >> putative partner). i guess npc people need it every day. >> >> thanks >> >> frido >> >> -- >> >> Friedrich Foerster >> Max-Planck Institut fuer Biochemie >> Am Klopferspitz 18 >> D-82152 Martinsried >> >> Tel: +49 89 8578 2651 >> Fax: +49 89 8578 2641 >> >> foerster@biochem.mpg.de >> >> www.tomotronic.org >> >> >> >> >> >> >> _______________________________________________ >> 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 >

--

Friedrich Foerster Max-Planck Institut fuer Biochemie Am Klopferspitz 18 D-82152 Martinsried

Tel: +49 89 8578 2651 Fax: +49 89 8578 2641

foerster@biochem.mpg.de

www.tomotronic.org

hi daniel,

the Model hierarchy is not particularly awkward by itself. for me the problem is more that dealing with a single hierarchy on the representation level is hard. i just constantly run into the problem that i want to press all my restraints and representation into a single hierarchy - and i always need to change it. so my hierarchy is basically just protein -> fragment. whether a fragment is an atom, few residues, a domain, or an entire protein varies from case to case. of course, i could add another layer - but it'd be quite a bit of work to change it everywhere and probably i'd need to change it again very soon. for me a convenient framework for restraints would probably look like that: rest1 = upper_distance(particles_from_protein_A, articles_from_protein_B) rest2 = upper_distance(particles_from_protein_A, articles_from_protein_C) final_restraint = lower_scoring_one_of(rest1, rest2) model.add_restraint(final_restraint)

(protein_B and protein_C are both of the same protein type, e.g., lysozyme ). for tricky cases one could use several instances of lower_scoring_one_of. just a proposal....

cheers

frido

On Dec 19, 2008, at 2:02 PM, Daniel Russel wrote:

> By the way, what exactly do you five cumbersome with the hierarchy > as it stands? Why do you find you are changing it a lot? Just > looking for ways to make things simpler.

--

Friedrich Foerster Max-Planck Institut fuer Biochemie Am Klopferspitz 18 D-82152 Martinsried

Tel: +49 89 8578 2651 Fax: +49 89 8578 2641

foerster@biochem.mpg.de

www.tomotronic.org

maybe that solution works for me. to be explicit: what happens to particles d,e,f, which have completely different restraints, which possibly require a different hierarchy? more importantly, what happens if c is affected by another restraint, which requires a different hierarchy? if i require a hierarchy that makes all restraints happy, that is my problem. if not, that is an improvement for me.

thanks

frido

On Fri, Dec 19, 2008 at 7:40 PM, Daniel Russel drussel@gmail.com wrote:

> Frido: > I am not sure I entirely understand you message. Would you consider it an > improvement to be able to do the following: > > # a,b,c are Particles which are MolecularHierarchyDecorator roots for the > proteins > # they can have arbitrary levels > > # the identifier for the equivalence class hierarchy > traits= HiearchyDecoratorTraits("equivlanence_class") > > abp= Particle() > m.add_particle(abp) > cp= Particle() > m.add_particle(cp) > # create a new hierarchy to define which proteins can be equivalently > connected > abh= HierarchyDecorator.create(abp, traits) > abh.add_child(HierarchyDecorator.create(a, traits)) > abh.add_child(HierarchyDecorator.create(b, traits)) > > # nothing else has the same type as c > ch= HierarchyDecorator.create(cp, traits) > ch.add_child(HierarchyDecorator.create(c, traits)) > > > # create a refiner to get all residues irrespective of how far down they > are in the hierarchy > refres= > DescendentsOfTypeParticleRefiner(MolecularHierarchyDecorator.get_type_key(), > > MolecularHierarchyDecorator.RESIDUE) > rtres = RefineOncePairScore(SphereDistancePairScore(), refres) > > # a refiner to produce the proteins in each equivalence class > cpr= ChildrenParticleRefiner(traits) > erops= RefineOncePairScore(rtres, cpr) > > # make a list of the particles defining the equivalence classes > classes= IMP.Particles() > classes.append(abp) > classes.append(cp) > r= ConnectivtyRestraint(erops, classes) > > The changes necessary to do the above are quite easy. > > > > On Dec 19, 2008, at 6:36 AM, Friedrich Foerster wrote: > > hi daniel, >> >> the Model hierarchy is not particularly awkward by itself. for me the >> problem is more that dealing with a single hierarchy on the representation >> level is hard. >> i just constantly run into the problem that i want to press all my >> restraints and representation into a single hierarchy - and i always need to >> change it. so my hierarchy is basically just protein -> fragment. whether a >> fragment is an atom, few residues, a domain, or an entire protein varies >> from case to case. of course, i could add another layer - but it'd be quite >> a bit of work to change it everywhere and probably i'd need to change it >> again very soon. >> for me a convenient framework for restraints would probably look like >> that: >> rest1 = upper_distance(particles_from_protein_A, articles_from_protein_B) >> rest2 = upper_distance(particles_from_protein_A, articles_from_protein_C) >> final_restraint = lower_scoring_one_of(rest1, rest2) >> model.add_restraint(final_restraint) >> >> (protein_B and protein_C are both of the same protein type, e.g., lysozyme >> ). for tricky cases one could use several instances of lower_scoring_one_of. >> just a proposal.... >> >> cheers >> >> frido >> >> On Dec 19, 2008, at 2:02 PM, Daniel Russel wrote: >> >> By the way, what exactly do you five cumbersome with the hierarchy as it >>> stands? Why do you find you are changing it a lot? Just looking for ways to >>> make things simpler. >>> >> >> -- >> >> Friedrich Foerster >> Max-Planck Institut fuer Biochemie >> Am Klopferspitz 18 >> D-82152 Martinsried >> >> Tel: +49 89 8578 2651 >> Fax: +49 89 8578 2641 >> >> foerster@biochem.mpg.de >> >> www.tomotronic.org >> >> >> >> >> >> >> _______________________________________________ >> 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 > >

thanks. looks exactly like what in need.

all the best for 2009

frido

On Wed, Dec 24, 2008 at 12:53 AM, Daniel Russel drussel@gmail.com wrote:

> I just added support for multiple hierarchies, so each particle can be part > of as many hierarchies as you want. So you can just make a new hierarchy > type per particle. > To make a new herarchy type you do: > ht= IMP.core.HierarchyTraits("my new hierarchy type") > then to use it you do > hd= IMP.core.HierarchyDecorator.cast(p, ht) > hd= IMP.core.HierarchyDecorator.create(p, ht) > hd= IMP.core.HierarchyDecorator(p, ht) > hd.get_child(0) > etc. > > I'll add example code shortly. > > On Dec 23, 2008, at 12:40 PM, Friedrich Foerster wrote: > > maybe that solution works for me. > to be explicit: > what happens to particles d,e,f, which have completely different > restraints, which possibly require a different hierarchy? > more importantly, what happens if c is affected by another restraint, which > requires a different hierarchy? > > > if i require a hierarchy that makes all restraints happy, that is my > problem. > if not, that is an improvement for me > > > > > thanks > > frido > > > On Fri, Dec 19, 2008 at 7:40 PM, Daniel Russel drussel@gmail.com wrote: > >> Frido: >> I am not sure I entirely understand you message. Would you consider it an >> improvement to be able to do the following: >> >> # a,b,c are Particles which are MolecularHierarchyDecorator roots for the >> proteins >> # they can have arbitrary levels >> >> # the identifier for the equivalence class hierarchy >> traits= HiearchyDecoratorTraits("equivlanence_class") >> >> abp= Particle() >> m.add_particle(abp) >> cp= Particle() >> m.add_particle(cp) >> # create a new hierarchy to define which proteins can be equivalently >> connected >> abh= HierarchyDecorator.create(abp, traits) >> abh.add_child(HierarchyDecorator.create(a, traits)) >> abh.add_child(HierarchyDecorator.create(b, traits)) >> >> # nothing else has the same type as c >> ch= HierarchyDecorator.create(cp, traits) >> ch.add_child(HierarchyDecorator.create(c, traits)) >> >> >> # create a refiner to get all residues irrespective of how far down they >> are in the hierarchy >> refres= >> DescendentsOfTypeParticleRefiner(MolecularHierarchyDecorator.get_type_key(), >> >> MolecularHierarchyDecorator.RESIDUE) >> rtres = RefineOncePairScore(SphereDistancePairScore(), refres) >> >> # a refiner to produce the proteins in each equivalence class >> cpr= ChildrenParticleRefiner(traits) >> erops= RefineOncePairScore(rtres, cpr) >> >> # make a list of the particles defining the equivalence classes >> classes= IMP.Particles() >> classes.append(abp) >> classes.append(cp) >> r= ConnectivtyRestraint(erops, classes) >> >> The changes necessary to do the above are quite easy. >> >> >> >> On Dec 19, 2008, at 6:36 AM, Friedrich Foerster wrote: >> >> hi daniel, >>> >>> the Model hierarchy is not particularly awkward by itself. for me the >>> problem is more that dealing with a single hierarchy on the representation >>> level is hard. >>> i just constantly run into the problem that i want to press all my >>> restraints and representation into a single hierarchy - and i always need to >>> change it. so my hierarchy is basically just protein -> fragment. whether a >>> fragment is an atom, few residues, a domain, or an entire protein varies >>> from case to case. of course, i could add another layer - but it'd be quite >>> a bit of work to change it everywhere and probably i'd need to change it >>> again very soon. >>> for me a convenient framework for restraints would probably look like >>> that: >>> rest1 = upper_distance(particles_from_protein_A, articles_from_protein_B) >>> rest2 = upper_distance(particles_from_protein_A, articles_from_protein_C) >>> final_restraint = lower_scoring_one_of(rest1, rest2) >>> model.add_restraint(final_restraint) >>> >>> (protein_B and protein_C are both of the same protein type, e.g., >>> lysozyme ). for tricky cases one could use several instances of >>> lower_scoring_one_of. >>> just a proposal.... >>> >>> cheers >>> >>> frido >>> >>> On Dec 19, 2008, at 2:02 PM, Daniel Russel wrote: >>> >>> By the way, what exactly do you five cumbersome with the hierarchy as it >>>> stands? Why do you find you are changing it a lot? Just looking for ways to >>>> make things simpler. >>>> >>> >>> -- >>> >>> Friedrich Foerster >>> Max-Planck Institut fuer Biochemie >>> Am Klopferspitz 18 >>> D-82152 Martinsried >>> >>> Tel: +49 89 8578 2651 >>> Fax: +49 89 8578 2641 >>> >>> foerster@biochem.mpg.de >>> >>> www.tomotronic.org >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > >