Re: Implement handles for nmrglue in relax -- November 27, 2014 - 11:53

Note that because nmrglue uses the BSD licence
(https://github.com/jjhelmus/nmrglue/blob/master/LICENSE.txt), we
could actually bundle the latest stable release with relax in the
extern/ directory.  This has the advantage of stability - if the
developers break the nmrglue API, we don't have to worry about
changing relax.  And we won't receive complaints from users that
something broke in relax when it was just an nmrglue API change.  For
any relax imports, we would always have to check if scipy is present
first.

Regards,

Edward



On 27 November 2014 at 11:47, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:
> Hi,
>
> I just saw your task #7873 (https://gna.org/task/?7873) which answers
> many of these questions.  For the design, this really depends on your
> specific goals.  We could create a new user function class called
> nmrglue.  However I think this would be a better fit for the spectrum
> user function class.  For example spectrum.nmrglue_create,
> spectrum.nmrglue_execute, spectrum.nmrglue_extract.  This matches the
> interaction with other software, see:
>
> dasha.create,
> dasha.execute,
> dasha.extract,
> palmer.create,
> palmer.execute,
> palmer.extract,
>
> relax_disp.catia_execute,
> relax_disp.catia_input,
> relax_disp.cpmgfit_execute,
> relax_disp.cpmgfit_input,
> relax_disp.nessy_input,
> relax_disp.sherekhan_input,
>
> molmol.macro_apply,
> molmol.macro_run,
> molmol.macro_write,
> molmol.view,
> pymol.macro_apply,
> pymol.macro_run,
> pymol.macro_write,
> pymol.view,
>
> bruker.read,
> grace.view,
> grace.write,
> spectrum.read_intensities.
>
> Note that in the future I plan on renaming the dasha and palmer user
> functions to model_free.dasha_create, model_free.palmer_execute, etc.
> All of this external software interaction should be standardised.
> Does this fit into your plans?
>
> Regards,
>
> Edward