Re: Specific analysis API redesign and relax 3.2. -- April 03, 2014 - 19:11

As these changes are quite disruptive, I will also merge the double_rotor branch back into trunk.  The differences are becoming too much of a hassle to deal with, as the specific_analyses.frame_order package in the trunk consists of a single __init__.py file while in the branch it has been split up for the API redesign.  And many changes in the branch are general for the frame order analysis and not specific to that branch.

Regards,

Edward

On 3 April 2014 19:07, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:

You may have noticed a lot of changes recently to the specific analysis API.  Due to too many circular import headaches with the frame order analysis coding, I decided to finally clean up the specific_analyses directories.  This has been on my mind for a long time.  The relaxation dispersion analysis was the first example of this cleaner design.

Previously the API consisted of one class per analysis.  Public methods implemented the API functionality.  But tonnes of private methods implemented everything else.  This has resulted in classes which were far too big.  Instead, the redesign is as follows:

- All analyses were converted from modules into packages.

- The API class has been shifted into the 'api' module.

- All private methods have been converted into functions in multiple modules based on their functionality (the method to function conversion was easy as none of the methods were storing information in 'self').  The different modules include:

  - 'checks', all functions for performing checks specific to the analysis.

  - 'data', all functions dealing with the base data of the analysis.

  - 'optimisation', all functions relating to optimisation, calculation, back calculation, etc., i.e. anything working with the target functions.

  - 'parameters', all functions relating to the models and model parameters.

  - 'uf', all functions which are the backend of a user function.

  - 'variables', all constants used in the analysis.

Other non-standard modules exist, for example for interfacing with different software, backwards compatibility, BMRB interoperability, etc.

In addition to the package/module layout redesign, the way the specific analysis API is called from the rest of relax is now much simplified.  The function specific_analyses.api.return_api() is now the standard and only way to access the API.  This will simply return the API object corresponding to the desired analysis.  This has allowed the API method naming to be standardised, and has resulted in the removal of a lot of old and ugly code.

As the API documentation (http://www.nmr-relax.com/api/) will now be significantly different, the next release of relax will be version 3.2.0.

Regards,

Edward