> * There are three columns listed that need (IMHO) further
> explanation. These are: "Amount" which I assume to be the amount
> by which the restraint is violated. "Calc Value" which might be
> the total r-6 average over all assignment-options for a given
> restraint and "Calc Error" for which I have no clue what it could
> mean.
The error is the error over all ambiguous constraint items. This will
change once ensembles are introduced.
> in "Contraints":
>
> * Violations seem to be calculated per assignment-option rather than
> per restraint (total r-6 average over all assignment-options)
> which reports many contraints as violated that are not considered
> as violated by CNS or Xplor-NIH.
Not true. All ambigous items under the constraint are considered but only
if they are ALL outside the range of a constraint will a violation be
issued. (At least that's the intention)
I could switch to calculating the violation value on the closest matching
item (perhaps better anyhow), if that's what you mean. Otherwise a
specific example would help.
> * It would be nice if violations were calculated for groups of
> structures rather than for single structures, giving more meaning
> to the "% Violated" in the "Violations" dialogue.
Structure ensemble use is planned as I have proabably mentioned before. I
just haven't go there yet amongst the myriad of other things. There also
data model issues here which need to be considered first.
> * The "Assign" button is a really big improvement over 1.0.9. Still
> a similar button that also allows to view the peak in its
> originating spectrum would be great. (I am aware that this
> requires some guessing or choosing of the Window to display the
> peak, and might therefore be difficult to implement).
Yes, the window is a problem which would add a fair amount of complexity.
Another issue is that a constraint may be derived from more than one peak.
Both of these points are covered by the fact that you can already do [View
Peaks] where you can see a list of peaks and find the peak in that list.
Anything more streamlined or specialised will have to wait, or you can
write a macro.
> in "edit Structures" :
> here some changes in handling the structures would be really helpful.
>
> * It would be good if structures had an editable "name"-tag (as
> constraint-lists) that would allow to give the structure a
> meaningful name. A field for "details" could do the job as well.
The Structure data model object does not have a "name" or a "details"
field.
Annotations will be applied to structure groups and ensembles when they
arrive in Analysis.
> * A way to organize structures into groups that result from the same
> run (but are not imported from ARIA2) would really help to do a
> more meaningful violation analysis (see above).
This is understood and already planned, my time is finite however..
The ARIA2 import does import a violation analysis on the ensemble.
T.
-------------------------------------------------------------------------------
Dr Tim Stevens Email: [log in to unmask]
Department of Biochemistry [log in to unmask]
University of Cambridge Phone: +44 1223 766022 (office)
80 Tennis Court Road +44 7816 338275 (mobile)
Old Addenbrooke's Site +44 1223 364613 (home)
Cambridge CB2 1GA WWWeb: http://www.bio.cam.ac.uk/~tjs23
United Kingdom http://www.pantonia.co.uk
-------------------------------------------------------------------------------
------ +NH3CH(CH(CH3)OH)C(O)NHCH(CH(CH3)CH2CH3)C(O)NHCH(CH2CH2SCH3)CO2- -------
-------------------------------------------------------------------------------
|