Hi,
Well, the target_functions.relax_disp and lib.dispersion code make
assumptions as to how the data they receive will look like. If this
is violated, then it will be random how different code paths fail. In
the numeric models, we use a special matrix_exponential() function
that I wrote, which itself calls numpy.linalg.eig(). The eig()
function is where the failure occurs. This function is not used in
the analytic models, so the same failure cannot be observed.
The best approach in designing the interface between the user and the
functional code is to perform comprehensive checks of what the user
has supplied. If things are missing or incorrect, raising a
RelaxError is the best way to give feedback to the user. Then we make
sure that we package the data up for sending to the target functions
only when all required data is supplied. Then the target functions
will always receive the data in the correct format. So the idea is to
block this code path - the optimisation - until everything is as we
expect. The only problem with the dispersion analysis is that I never
had the time to add fully comprehensive checking. Therefore we can
add checks as users encounter and report problems.
Regards,
Edward
On 19 May 2014 12:41, Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxx> wrote:
Hi Ed.
That sounds fine.
But what troubles me, is that the methods differ.
Why can the numeric models not handle this?
This sets off an alarm for me, showing that something is not consistent
and designed correct.
Best
Troels
2014-05-19 9:53 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:
Hi Troels,
There are two ways to solve this bug:
1) Have the relaxation dispersion code which assembles the data from
the current data pipe into the form required for the target functions
handle the problem.
2) Have relax give RelaxErrors preventing the user from doing anything.
Number 1) is by far the most difficult! The reason is because there
are an incredible number of ways users can input data. The number of
data combinations is huge. Number 2) would be much easier - simply
present to the user:
RelaxError: Two magnetic fields detected but data only present for one.
This could be a single function added to
specific_analyses.relax_disp.checks which is called at the start of
the minimise() API method (and any other user functions that require
it). As users discover other invalid data combinations - which they
most definitely will - then we just add more and more check_*()
functions to raise RelaxErrors. This is what happens in all the other
specific analyses. Rather than handling all possible ways a user can
fit data into relax, which would require huge amounts of complex code,
we simply raise RelaxErrors telling the user what is wrong with their
data input. This involves only a few 10 line max check_*() functions.
In this case, the user can then decide to delete the metadata, not
set it up, or load the required data. I would highly recommend this
simple solution.
Regards,
Edward
On 18 May 2014 22:41, Troels E. Linnet <NO-REPLY.INVALID-ADDRESS@xxxxxxx>
wrote:
Follow-up Comment #5, bug #22017 (project relax):
This bug persists, since it will work when:
model_create = MODEL_NS_CPMG_2SITE_EXPANDED
model_create = MODEL_CR72
Somehow these models:
model_create = MODEL_NS_CPMG_2SITE_3D
model_create = MODEL_NS_CPMG_2SITE_3D_FULL
model_create = MODEL_NS_CPMG_2SITE_STAR
model_create = MODEL_NS_CPMG_2SITE_STAR_FULL
will fail to produce the data.
The point of fails, is before the R2eff values have been created for the
other
timepoint.
But it should not be necessary.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?22017>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
Re: [bug #22017] LinAlgError, for all numerical CPMG models.