[phenixbb] GUI display items

Felix Frolow mbfrolow at post.tau.ac.il
Sat Mar 9 22:44:42 PST 2013


I find convenient (to follow after structure development) to produce, store and use bulk data which is present in Table 1.
Table 1 can be easily produced and conveniently displayed. 
Dr Felix Frolow   
Professor of Structural Biology and Biotechnology, Department of Molecular Microbiology and Biotechnology
Tel Aviv University 69978, Israel

Acta Crystallographica F, co-editor

e-mail: mbfrolow at post.tau.ac.il
Tel:  ++972-3640-8723
Fax: ++972-3640-9407
Cellular: 0547 459 608

On Mar 10, 2013, at 01:47 , Nathaniel Echols <NEchols at lbl.gov> wrote:

> On Sat, Mar 9, 2013 at 5:08 AM, Machius, Mischa Christian
> <mischa_machius at med.unc.edu> wrote:
>> I don't know how difficult the following would be to implement in your current system, so forgive me if it's too ambitious:
>> Ideally, the user would be able to choose what to display. I am thinking of a column info system along the lines of iTunes where one can select which data should be shown (right-click on any column header). One should also be able to sort on any column (ascending/descending).
>> 
>> Things to show would include (nut are not limited to):
>> R, Rfree, Rfree-R, variation of LLG and R factors in the last cycle compared to penultimate cycle (to test for convergence), Ramachandran outliers, rotamer outliers, clash score, input weights, LLG, map correlation coefficients, etc., all the goodies :)
> 
> Basically the problem right now is that almost all of these are stored
> in separate files, one per job - the R-free is shown in the job
> history because it's the only statistic stored centrally.  In order to
> display these other statistics and sort them, I either need to
> significantly refactor the way the job data are stored, or read in the
> files for every job to extract the necessary information.  I'm a
> little concerned about the overhead involved - the reason they're
> stored separately is to be able to load the basic job history as
> quickly as possible.  I think there is a way to minimize this by
> caching some of the data, but it's not trivial, and will probably take
> me several tries to get it right.
> 
> -Nat
> _______________________________________________
> phenixbb mailing list
> phenixbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/phenixbb/attachments/20130310/218557fa/attachment.htm>


More information about the phenixbb mailing list