Vitaliy,

It would be handy for analysis to have this capability but currently that job is usually left to the downstream structure calculation program. I think there are practical reasons for leaving it in the realm of the structure calculation program, because merging of restraints will go differently at different stages of disambiguation of the restraints. One should also take into account the reasons for merging restraints - in analysis generally a restraint has (but does not have to have) a direct correspondence to an experimental observation. In structure calculations one merges restraints (mainly) to improve the efficiency of the calculations and somehow avoid overweighting certain observations.
The scheme that Rasmus sets out below is more or less what ARIA/CNS does, and though I'm less familiar with XPLOR-NIH and CYANA, I imagine they have similar functionality. For XPLOR at least, there are the ARIA 1.x XPLOR scripts that can be used without using the whole ARIA scheme to accomplish the merging of constraints where MN's group have already done the thinking for you about what groups should be considered as equivalent and so eligible to be merged.

Yours,
Brian
________________________________________
From: CcpNmr software mailing list [[log in to unmask]] On Behalf Of Vitaliy [[log in to unmask]]
Sent: 10 September 2013 02:50
To: [log in to unmask]
Subject: Re: Merge duplicates in Restraint

Hopefully someone in this respectful community could read through this long correspondence and come up with idea/suggestion on how the situation should be handled within Analysis. Please read bellow.
Thank you,
Vitaliy

> Date: Mon, 9 Sep 2013 13:20:54 +0100
> From: [log in to unmask]
> To: [log in to unmask]
> CC: [log in to unmask]
> Subject: RE: Merge duplicates in Restraint
>
> Dear Vitaliy,
>
> You are right. We should.
>
> Do you have time to get it into some half-way legible shape and send it?
>
> Thanks,
>
> Rasmus
>
> ---------------------------------------------------------------------------
> Dr. Rasmus H. Fogh Email: [log in to unmask]
> Dept. of Biochemistry, University of Cambridge,
> 80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
>
> On Sat, 7 Sep 2013, Vitaliy Gorbatyuk wrote:
>
> > Dear Rasmus,
> > I just noticed that this conversation was not sent to the ccpn mailing list.
> > Should we post it (without my project) there so that people can get
> > involved?
> > Regards,
> > Vitaliy
> >
> > > Date: Thu, 5 Sep 2013 06:20:22 +0100
> > > From: [log in to unmask]
> > > To: [log in to unmask]
> > > CC: [log in to unmask]
> > > Subject: RE: Merge duplicates in Restraint
> > >
> > > Dear Vitaliy,
> > >
> > > The program could detect restraints that had almost the same set of
> > > nuclei involved. After that, though, one would need to decide exactly what
> > > to do with them. One possibility would be to merge if the atoms on one
> > > restraint were a subset of the atoms on the other, and the distance limits
> > > were within a tolerance of each other. Then one would have to put the
> > > option into the user interface, and explain well enough that people could
> > > find and understand what was happening. An alternative would be to make a
> > > list of restraints that might warrant a merge, and let the user take it
> > > from there.
> > >
> > > In practice we are likely to be too busy with version 3 for quite some
> > > time to be able to do this. If our collective users could come up with a
> > > precise description of what should be done it would help, but even so it
> > > is unlikely to be happening any time soon, I am afraid.
> > >
> > > Yours,
> > >
> > > Rasmus
> > >
> > >---------------------------------------------------------------------------
> >
> > > Dr. Rasmus H. Fogh Email: [log in to unmask]
> > > Dept. of Biochemistry, University of Cambridge,
> > > 80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
> > >
> > > On Thu, 5 Sep 2013, Vitaliy Gorbatyuk wrote:
> > >
> > > > Dear Rasmus,
> > > >
> > > > Thank you very much for looking into this potential problem. Indeed, you
> > are
> > > > absolutely right that strictly speaking the restraints are different.
> > > >
> > > > These restraints originated from the different runs of the structure
> > > > calculation and, no surprise, they have different sets of contributing
> > pairs
> > > > of protons. But as you said they are the same in practice and manually
> > we
> > > > might want to merge them. Going through such huge table and trying to
> > fish
> > > > out such restraints is a tedious task. So I wonder if some changes could
> > be
> > > > made to the code which would let the user know about existence of such
> > > > restraints and asking the user what to do with them. I suspect such
> > > > restraints could be seen quite often, and not only when we merge several
> > > > restraint sets, but also they may come from different spectra where the
> > > > structure calculation software gives them different ambiguity. But
> > again, in
> > > > practice the major contributing pair is the same. Now, after we export
> > the
> > > > restraint list into Xplor, for example, we will have a problem since we
> > will
> > > > provide two-three restraints for the same pair of protons....
> > > >
> > > > The work around which I can see is splitting ambiguous from unambiguous.
> > > > Thus, the table is smaller and more convenient to work with. But some
> > such
> > > > restraints may be unambiguous in one list and ambiguous in another...
> > Hope
> > > > you can come up with your idea.
> > > >
> > > > Again thank you very much for your help and the great software!
> > > >
> > > > Regards,
> > > > Vitaliy
> > > >
> > > > > Date: Tue, 3 Sep 2013 11:57:59 +0100
> > > > > From: [log in to unmask]
> > > > > To: [log in to unmask]
> > > > > CC: [log in to unmask]
> > > > > Subject: RE: Merge duplicates in Restraint
> > > > >
> > > > > Dear Vitaliy,
> > > > >
> > > > > This is actually OK, I think.
> > > > >
> > > > > If you sort on the Resonances column you do see the two duplicate
> > > > > assignments you mention. But if you sort on the '#' column again, you
> > get
> > > > > the actual restraints. The two relevant ones here are:
> > > > >
> > > > > # 5619
> > > > > limits 1.744-3.392
> > > > > Assignments:
> > > > > 24 Met Ha : 24M He*/27L Hba/27L Hbb || 84K Ha : 102K Hba
> > > > >
> > > > > # 6927
> > > > > limits 1.75-3.404
> > > > > Assignments:
> > > > > 24 Met Ha : 27L Hba/27L Hbb || 84K Ha : 102K Hba
> > > > >
> > > > > As you see, these are two different ambiguous restraints. The possible
> > > > > assignments are not the same. Indeed, since 5619 is tighter than 6927,
> > it
> > > > > is theoretically possible that 6927 is satisfied by one of the three
> > > > > possibilities, wheras 5619 is satisfied only by 24 Met HA - 24 M He*.
> > > > >
> > > > > If you compare restraints 1109 and 6969, you again see that the
> > tighter
> > > > > restraint has more possible assignments than the looser restraint
> > > > >
> > > > > Of course it is clear to the human eye that this is the same restraint
> > in
> > > > > practice, and a closer look at the peak(s) it arises from would no
> > doubt
> > > > > allow a manual merge. But on strict mathematics these two restraints
> > are
> > > > > not mutually redundant, and the program is correct in keeping both.
> > > > >
> > > > > One could mess about with adding a tolerance, so that almost identical
> > > > > upper limits are treated as identical, but I do not think it is worth
> > it.
> > > > > Particularly since you could get the same problem where each of the
> > two
> > > > > restraints had an assignment possibility that the other one lacked.
> > > > > Anyway, the only problem is that we have slightly more correct
> > restraints
> > > > > than we would ideally wish.
> > > > >
> > > > > Yours,
> > > > >
> > > > > Rasmus
> > > > >
> > > > >
> > > >>--------------------------------------------------------------------------
> > -
> > > >
> > > > > Dr. Rasmus H. Fogh Email: [log in to unmask]
> > > > > Dept. of Biochemistry, University of Cambridge,
> > > > > 80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
> > > > >
> > > > > On Tue, 3 Sep 2013, Vitaliy Gorbatyuk wrote:
> > > > >
> > > > > > Dear Rasmus,
> > > > > >
> > > > > > Thank you for getting back to me. I have attached the short version
> > of
> > > > the
> > > > > > ccpn project (the full version is 37MB). Please have a look at the
> > > > restraint
> > > > > > set 57, list 5. For example, 24MetHa has two restraints with
> > 27LeuHba as
> > > > > > well as the two restraints with 27LeuHbb.
> > > > > >
> > > > > > Please let me know if you need anything else from me.
> > > > > >
> > > > > > Thank you,
> > > > > > Vitaliy
> > > > > >
> > > > > > > Date: Mon, 2 Sep 2013 17:00:34 +0100
> > > > > > > From: [log in to unmask]
> > > > > > > Subject: Re: Merge duplicates in Restraint
> > > > > > > To: [log in to unmask]
> > > > > > >
> > > > > > > Dear Vitaliy,
> > > > > > >
> > > > > > > Back from holiday, and it looks like this never got answered.
> > Could
> > > > you
> > > > > > > send me the zipped-up project (minus spectra), and tell me which
> > > > restraint
> > > > > > > lists you had merged? Then I can take a look at it.
> > > > > > >
> > > > > > > Yours,
> > > > > > >
> > > > > > > Rasmus
> > > > > > >
> > > > >>>-------------------------------------------------------------------------
> > -
> > > > -
> > > > > >
> > > > > > > Dr. Rasmus H. Fogh Email: [log in to unmask]
> > > > > > > Dept. of Biochemistry, University of Cambridge,
> > > > > > > 80 Tennis Court Road, Cambridge CB2 1GA, UK. FAX (01223)766002
> > > > > > >
> > > > > > > On Wed, 21 Aug 2013, Vitaliy wrote:
> > > > > > >
> > > > > > > > Hello developers,
> > > > > > > >
> > > > > > > > I had several restraint lists which I merged into one list and,
> > > > then,
> > > > > > > > applied MergeDuplicates. However there are still duplicates in
> > the
> > > > list.
> > > > > > > > Among the original lists I had a list which was imported from
> > Xplor.
> > > > The
> > > > > > > > other two restraint lists were imported from Aria.
> > > > > > > >
> > > > > > > > I would appreciate your help,
> > > > > > > >
> > > > > > > > Vitaliy
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >