Sound all good! So I will wait until you modify the image-folder and patch the model-free calculation, although I am a bit concerned that teher is a problem (maight be the grid search step).
Cheers Edward d'Auvergne schrieb: >>> 1) Each new analysis appears not as tabs but as a new window. This >>> would be similar to oowriter or MS Word, where there is a 'Window' >>> menu where one can switch between the analyses. This is also similar >>> to what sparky does. Either there is an entire new window for each >>> analysis, or it could be done as now where each is in a tab (just that >>> you don't show the tab bit). Each analysis can be created at any >>> time, and closed at any time. The window with buttons with pictures >>> of each analysis type can appear at the start and also when clicking >>> on 'File -> New analysis'. >>> >>> >> I somehow like the idea that the whole relaxation analysis is in one >> window, separated by tabs. This helps to keep all the informations >> together. I would suggest to split the kind of dynamics calculation, >> i.e. model-free, dispersion.... >> > > These could be grouped - the R1, R2, and NOE. But I would still try > to make this flexible and not assume a protein NMR spectroscopist has > measured these standard things at 2 field strengths. What if a > chemist came with R1 data collected at 100 different field strengths > using special equipment? The point here is that you should not force > upon the user a way of doing something because some user will always > want to do something differently. If they can click on 'File -> New > analysis' and select R1 from the analysis selection window, and repeat > this 100 times, they would not complain about relax. relax can do > this without problems so this would be a constraint on them 100% > enforced by the GUI. It should be dynamic - I want to add this type > of analysis, save then close this one, etc. It makes the GUI coding a > bit more difficult but improves the usability and power of the GUI > immensely. I have specifically designed relax to be incredibly > flexible, allowing the user through the prompt and script interfaces > to do almost anything they can imagine. Most will just use > pre-written scripts, but this flexibility is incredibly useful. I > would be very sad, that if after so much effort designing a program > with so much flexibility (almost any type and amount of data input) > and support for all types of systems (small molecules, RNA, DNA, > proteins, sugars, etc.), that the GUI then takes this all away :( > > > >>> 2) The code paths are too complex! This can be done after the paper, >>> but please don't discount this. If I would like to make modifications >>> to or debug the model-free code (GUI and calculation), I have to jump >>> all over the place and have to separate it in my mind from all the >>> other code. I would suggest a big rearrangement of the code, to make >>> it more like lego where you have reusable blocks. Firstly, what does >>> the directory 'res/' stand for? I cannot for the life of me work out >>> why you have this directory! I would propose the following, logical >>> directory structure: >>> >>> gui_bieri/ -> All the GUI element modules (filedialog.py, >>> settings.py, etc) go in the base directory. In the future when the >>> interface is more complex, the GUI elements could be grouped and >>> shifted into packages (directories). >>> gui_bieri/analyses/ -> All the analysis specific code goes here. >>> I.e. 'gui_bieri/analyses/model_free.py', 'gui_bieri/analyses/r1.py', >>> etc. >>> gui_bieri/oxygen_icons/ -> Have dedicated directories for material >>> that is differently, but legally licenced! The may shift down a >>> directory to the base relax directory when other types of GUI are >>> added. >>> gui_bieri/images/ -> All the bitmap pictures go here. I would >>> suggest that for the future of the project, that SVG versions whenever >>> possible are placed here. This will allow for better image resizing, >>> tiny icons to be made, etc. >>> gui_bieri/execution/ -> All the calc_* modules can be shifted here. >>> Or alternatively it goes into gui_bieri/analyses/ as well. >>> >>> >> sure! I just placed everything into the res (from resources) folder. but >> it's getting messy and overfilled now! >> > > Give the word and I'll make all the file rearrangements necessary in > the repository. If you make any changes during this time, you will > need to manually shift the changes around (move the modified files to > the new locations). I would also like to have some point in time > reserved for the whitespace fixes. This is very important! I cannot > emphasise this enough! > > > >>> 3) Code recycling. Many analysis types re-use the same user >>> functions. For example model-free, J(w) mapping, consistency testing, >>> and in the future SRLS and other analysis types will all use relation >>> data input. Therefore this GUI element could be separated and each >>> analysis type then places where it likes. I would suggest that it >>> looks as follows (100% redesign). There is a canvas (forgotten the >>> GUI element name here) which displays the loaded relaxation data, >>> displaying a label (ri_label and frq_label will soon be combined so >>> Sebastian can better work with relaxation dispersion data) and the >>> frequency in MHz. Each can be selected by clicking on them. Then >>> there are a series of buttons on the right hand side. A big + icon >>> adds new data, and opens a dialog box to select the file, specify the >>> label, the frequency, all the column numbers, the column separator, >>> and allowing a spin_id selector to only load a specific subset of the >>> data. A big - icon can remove data. Another icon can display the >>> data for all spin systems. Therefore I would suggest a module called >>> 'gui_bieri/relax_data.py' for this that can be imported by >>> 'gui_bieri/analyses/model_free.py'. The relaxation data input GUI >>> element can then be modified/expanded at any time independent of the >>> rest of the GUI. >>> >>> >> I would suggest to have an initial window that shows which calculations >> (modelfree, J(w)...) can be performed by relax. Under these buttons, we >> could have a list or tree that shows projects that are already >> calculated or in the middle of analysis. So users can either start a new >> analysis or continue. >> > > I don't think the tree is necessary as we could switch between them > through the 'Window' menu. This is the standard way to perform this > in most programs. > > As for point 3), I was talking about the data input for an analysis - > i.e. the current model-free 3 frequency relaxation data input table. > This is not related to the analysis selection window that can appear > at the start and after clicking on 'File -> New analysis'. > > > >>> 4) PyMOL (http://www.pymol.org/). This is open source and can be >>> imported as a python module. Therefore I propose as a future idea >>> that we bundle this with relax, import it in >>> 'gui_bieri/molecular_viewer', and provide its OpenGL canvas to display >>> the results of the analyses to each analysis type. Not the PyMOL GUI >>> - this sucks - but the OpenGL canvas GUI element. This could possibly >>> appear in a new window, as a new tab, or even as part of the main >>> window using buttons to switch rather than tabs. We can then provide >>> relevant functions as menu entries - 'Display diffusion tensor', >>> 'Display data' where S2, te, Rex, CSA, J(0), J(wN), etc can be mapped >>> onto the structure, 'Write PNG', 'Ray trace', etc. This would make >>> the relax GUI much more awesome! >>> >>> >> this would be very cool!! >> > > It would be, and many people are interested in this and what it can do > for relax. It would also allow 3D geometric object to be drawn, which > for dynamics could be very useful. Or even to generate alignment > tensor pictures attached to the molecule. > > > >> what do you think about the future of relax? do want to drive it in a >> more GUI like application, so future elements are designed together with >> a GUI? >> > > This has been decided a long, long time ago. It is all written out in > the relax manual in section 9.7, 'The core design of relax'. The > different user interfaces are all part of the program, but note that > relax is a massive software project. Therefore to keep this codebase > sane and alive, there are clear APIs between different parts of the > program. And the UI's must respect these. If new functionality is > needed, it is added to the correct part of the code base and accessed > through these APIs. 'generic_fns' is easy as this is just a bunch of > functions to import. 'specific_fns' is more advanced and a cleaner > API. This is for the different analyses where they must provide > certain methods so that minimisation, for example, just works without > modification to the minimisation code. The permanent data storage is > in the relax data store - with no exceptions. These APIs will stay, > and will become more and more refined as the program evolves. > > My contributions to relax are currently in the areas of the N-state > model and Frame Order theories. These are different in that RDCs, > PCSs, NOEs, J-couplings, etc. are being used to obtain dynamic > information. In the case of the N-state model, this is being used to > solve stereochemistry questions in chemistry. The Frame Order > theories will hopefully be completed soon and presented at the ICMRBS. > Other people are taking the program in other ways, for example see > the next paragraph. > > Note that the GUI is only one of many UI's that will go into relax. > Another one planned is a web interface allowing a user to run > calculations over the internet. One use that Gary Thompson has talked > about is to set up a server that people can submit relaxation data to, > and have the final model-free results returned to them. So the web > interface and the multi-processing code will very naturally fit > together. Then there are the script and prompt interfaces that those > with massive clusters will probably want to always use. Other > interfaces have been proposed in the past, and may return in the > future. > > I also use relax as a toolkit. I can write python scripts and import > and use relax functions (just by running the python script as a relax > script). This gives me instant access to a PDB reader/writer, to many > mathematical functions, to the convenient relax data store that I can > use to store atom specific data (unrelated to dynamics). The > generic_fns.mol_res_spin.spin_loop() function is incredibly useful! > > > >> I am currently also working on a software that analyzes dispersion data >> (at the moment cp-CPMG). There, I completely build everything in a GUI, >> which facilitates a lot of issues about preparing input files. Peak >> files are just loaded in an excel-like grid. Users choose which are >> residue number columns and data columns. Like this, a lot of formatting >> problems are avoided. >> If you would like, we could fuse these programs as well! >> > > I suggest you talk to Sebastian Morin (https://gna.org/users/semor) as > he is the owner of the relaxation dispersion branch > (http://svn.gna.org/viewcvs/relax/branches/relax_disp/)! We are > currently designing how to input the base data, and this will probably > result in the 'ri_label' and 'frq_label' being merged into one. > > > >> There is another idea: >> Wouldn't it be great if the user only needs one HSCQ assignment (or >> TROSY for better dispersion data) and relax(GUI) reads in all the >> recorded spectra, finds peaks, groups them and start the analysis? This >> would be a really fat automatic software! >> > > This can be done without problem. For the relax design, the GUI would > fully control this, but most of the work would be performed by > functions in the 'generic_fns' package. User functions can be > designed at the same time or afterwards. For example spectra.read() > would be a useful user function that then performs the same thing as > the GUI, both going through the API and calling a single function in > the 'generic_fns' package. Both can be written at the same time (see > the test suite comments below for why this should be done). This > function would then store this data in the relax data store. > > Who ever implements this would end up with a very impressive paper. > People are looking at automatic structures (raw spectra to final > structure) but no one that I know of is trying to do the same with > dynamics! > > > >> The main issue would be to have a good peak picking algorithm included. >> I know that Mehdi Mobli (IMB) is writing a promising one. We will have a >> collaboration about dynamics in 2 weeks and I could ask him to join. >> What do you think about this? >> > > If you'd like this in relax, you are totally free to do this. And it > would be a most welcome and awesome addition! But it will need to > follow the relax design with the clean code separations. You will > need to familiarise yourself more with the overall design of relax. > And also improve your coding abilities - i.e. more comments, no > whitespace issues, module/class/function docstring writing, commit > messages following the rules, etc. You'll have to do this to avoid > jumping on other peoples toes and breaking their code. You will need > to understand the test suite, and implement user functions at the same > time as GUI functions so scripts can be written and, together with > basic test cases, added to the test suite. I would suggest carefully > reading all of chapter 9 of the relax manual. > > It will be difficult to come to grips with this huge code base, but in > the end it should be worth it. And I and the other relax developers > can guide you through this jungle. > > > >> There is a lot we can do to get relax THE software for protein dynamics! >> > > It's already there ;) Art Palmer is recommending people to use relax > rather than his program! I'm extending the program to other analysis > types. Sebastian Morin as well. Gary Thompson worked hard on > parallelising relax to run on massive clusters, and soon people will > be able to benefit from that. Chris MacRaild has made many numerous > improvements all over the code base, important things that everyone > now takes for granted. BMRB support is coming very soon which will > allow smooth flow of dynamics data into that data base. CCPN support > is planned for the future (I was just talking to Rasmus today). > Others are planning on expanding relax to other domains - for example > to revolutionise dynamics and its understanding in chemistry. > > But adding a flexible GUI will make relax even more awesome! And an > automatic process - from raw data to dynamics description - would be > huge. But I seriously expect that each one of these new additions > would result in a paper - otherwise I would be disappointed. > Minimally a very short communication of a few paragraphs must be > written. > > Cheers, > > Edward > > _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
