Hi Edward. That sounds very interesting. :-)
I still have a very little clue of how the organization of files are structured, so I have a little hard time to comment on it. But I really like the idea, to be able to extract different kind of information from the same file. I also think I would have a hard time helping, until your reconstruction have finished. So, I guess I will move on with the models in relax_disp branch I need for my data, and wait for your reconstruction. Then I would like to be able to make the ability to read the model from the intensity files. Keep me informed if there is something I can help with. Best Troels Troels Emtekær Linnet 2013/8/9 Edward d'Auvergne <[email protected]> > Hi, > > I like the idea of reusing the code! I've been thinking and maybe > there is an even better solution, one that is much more flexible. I > am trying to shift as much code as possible into the relax library. > Any code which does not relate to the specific analyses or does not > touch the relax data store should be shifted into the relax library. > The whole concept of reading peak list data fits into this. So I'm > wondering about creating a new module called lib.spectrum and creating > a function called read_peak_list(). This function would then be used > to read all types of data from a peak list, independent of the format > of that list. With this, a lot of code from > pipe_control.spectrum.read() would be shifted into this new function. > So instead of using pipe_control.spectrum.read(), you call > lib.spectrum.read_peak_list() to do all the work. The generic peak > list code in pipe_control.spectrum would also shift into lib.spectrum. > > One reason this would be useful is because I will likely implement the > reading of chemical shifts from these peaks lists for the > off-resonance R1rho support in the relax_disp branch. This would > likely go into a new module called pipe_control.chemical_shift. This > code could then call the lib.spectrum.read_peak_list(). The > pipe_control.spectrum.read() function could be renamed to > pipe_control.spectrum.read_intensities() and call this function too. > And the spectrum.read_sequence user function backend is called > pipe_control.spectrum.read_sequence() which also calls this function. > The spin ID can be then built by each pipe_control function, but only > if required. For example, when generating the sequence data as spin > ID is not needed. It's only used to return a pre-existing spin. But > the spin ID generation function is dependent on the relax data store, > so it cannot be called from the relax library. > > For the lib.spectrum.read_peak_list() function, we could have > arguments to select if the chemical shifts should be returned, the > peak intensity, etc. One argument for each type of data present in a > peak list, all defaulting to None. This function can return the > molecule name, residue name, residue number, spin name, and spin > number (defaulting to None when no data is present) as the first > elements, followed by what ever other data is asked for. What do you > think? > > Regards, > > Edward > > On 9 August 2013 12:11, Troels Emtekær Linnet <[email protected]> wrote: > > Hi Edward. > > > > Thanks for your suggestions. > > > > I was carried away, to try to make some GUI changes. > > Just to see, how it worked. > > > > So, I have thought a little about the design since then. > > > > I was thinking to take advantage of the: .\pipe_control\spectrum.py > read() > > function. > > > > I already provides a spin_id in its functions. > > > > And so the functions could be modified to create spins instead of reading > > the > > intensities. > > > > I think the easiest would be to provide another keyword to the read() > > function. > > Something like: return_model = False > > > > If then read() is called with return_model = True > > the checks and reading of intensities are skipped, but the > > spin_ids are returned. > > > > What do you think of this? > > > > > > > > > > Troels Emtekær Linnet > > > > > > 2013/8/3 Edward d'Auvergne <[email protected]> > >> > >> Hi, > >> > >> It might be better to discuss the design a bit before. I've looked at > >> the patches and although half are ok, I think it is a little too > >> specific for relax. By that I mean that this idea can be generalised, > >> as is the design goal for most of relax. So instead of being Sparky > >> specific, everything should be generalised to be a 'peak list'. That > >> way support can be added for NMRPipe series Tab, NMRView, XEasy, Cara, > >> CCPN, etc. later much more easily - i.e. only the user function front > >> and backends need to be modified. That is how the > >> spectrum.read_intensities user function works. > >> > >> For the user function name itself, the best might be > >> spectrum.read_sequence. Though an alternative place might be under > >> sequence.peak_list. The first one might be more logical from the code > >> perspective as the backend will be in pipe_control.spectrum. But I'm > >> not sure for a user which would be easier to find. > >> > >> Anyway, your patches won't take much to modify. However I think > >> patches 0001 to 0005 should be one commit. 0006 would need a little > >> work. I think that *.* should be the default for the file arguments, > >> and then the user can select *.ser, *.xpk, *.list and *.text (for > >> NMRPipe, NMRView, Sparky and XEasy) to be more specific when selecting > >> the file. I think that the molecule should also be left unnamed if > >> the user does not supply a molecule name. They can always use > >> molecule.name later. It also needs a description and title along the > >> lines of the sequence.read user function, as its front end design and > >> its aim are similar. So the title might be "Read the molecule, > >> residue, and spin sequence from a peak list.". And the short title > >> something like "Sequence reading from peak lists.". What do you > >> think? > >> > >> Patch 0007* has the trailing whitespace removal problem, so it seems > >> like you haven't fully eliminated that issue. In this case that > >> whitespace should be removed, but it should be a separate trivial > >> patch. The code is also in the wrong place, the backend should be in > >> pipe_control.spectrum, and it should be modelled on the read() > >> function (maybe called read_sequence()). The 0008* patch is also > >> quite far off target. This is why it is better to discuss a design > >> idea on the mailing list before implementing it. With discussions, > >> the best solution can be found from the start. > >> > >> Cheers, > >> > >> Edward > >> > >> > >> > >> On 3 August 2013 08:56, Troels E. Linnet > >> <[email protected]> wrote: > >> > Follow-up Comment #2, sr #3044 (project relax): > >> > > >> > Initial tries for a SPARKY/NMRPipe seriesTab GUI read of spins. > >> > > >> > If these patches are ok, it would be time to establish system tests, > and > >> > I > >> > hope for a little guide in which files these should be written. > >> > > >> > (file #18632) > >> > _______________________________________________________ > >> > > >> > Additional Item Attachment: > >> > > >> > File name: sparky1.patch.tar.gz Size:4 KB > >> > > >> > > >> > _______________________________________________________ > >> > > >> > Reply to this item at: > >> > > >> > <http://gna.org/support/?3044> > >> > > >> > _______________________________________________ > >> > Message sent via/by Gna! > >> > http://gna.org/ > >> > > >> > > >> > _______________________________________________ > >> > relax (http://www.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 > > > > >
_______________________________________________ relax (http://www.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
