Hi Troels,
These two new tests are problematic in that they are no longer unit
tests. Unit tests for the lib.dispersion modules should only check
the lib.dispersion module functions. But here this is also checking
the specific analysis parameter object API. They are also problematic
in that
(R2eff)):
R2eff = array([1e100]*num_points)
Best
Troels
2014-05-28 17:29 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
These two new tests are problematic in that they are no longer unit
tests. Unit tests for the lib.dispersion modules should only check
Hi Troels,
I think this TP02 model in the 'no Rex' edge cases should return:
R1rho = R1 cos^2(theta) + R1rho' sin^2(theta)(1)
rather than:
R1rho = R1rho'(2)
The problem is in the unit tests in
test_suite/unit_tests/_lib/_dispersion/test_tp02.py, specifically the
calc_r1rho()
Hi Troels,
Note that you should do this for all R1rho model types. Exceptions
are the 'M61' and 'M61 skew' models which are on-resonance, hence they
should return arrays of R1rho' as theta is always 0.0.
Regards,
Edward
On 27 May 2014 09:14, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi
Hi Troels,
I have spotted a bug in this change. The reason it is a bug is
because of the 'MMQ CR72' equations
(http://www.nmr-relax.com/manual/MMQ_CR72_model.html). A value of dwH
== 0.0 does not result in no exchange if dw != 0.0. The converse is
also true, there is exchange when dw == 0.0 if
Hi Troels,
As I mentioned previously
(http://article.gmane.org/gmane.science.nmr.relax.devel/5938), the
R1rho value checking in these unit tests contains a bug.
Regards,
Edward
On 26 May 2014 23:09, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Mon May 26 23:09:45 2014
New Revision:
Hi Troels,
You may wish to revert this change due to the unit test bug:
http://article.gmane.org/gmane.science.nmr.relax.devel/5938
Cheers,
Edward
On 26 May 2014 23:09, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Mon May 26 23:09:47 2014
New Revision: 23441
URL:
Hi Troels,
You've probably already gotten the idea:
http://article.gmane.org/gmane.science.nmr.relax.devel/5938
;)
Edward
On 26 May 2014 23:09, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Mon May 26 23:09:50 2014
New Revision: 23442
URL:
Hi Troels,
On top of the bug described at
http://article.gmane.org/gmane.science.nmr.relax.devel/5938, there is
a second bug here. I highly recommend reverting this commit.
The second bug is the deletion of the gamma 0.0. This is absolutely
essential, as later the square root of gamma is
Hi Troels,
Due to the problem I mentioned of either dw or dwH being zero but
still seeing exchange
(http://article.gmane.org/gmane.science.nmr.relax.devel/5940), I would
recommend that you modify these tests as follows. I would modify all
the tests where dw = 0.0 to be where both dw and dwH are
Hi Troels,
I have a suggestion for this change too, specifically:
@@ -123,6 +129,8 @@
# The next lines calculate the R2eff using a two-point
approximation, i.e. assuming that the decay is mono-exponential.
Mx = fabs(Mint[1] / pA)
if Mx = 0.0 or isNaN(Mx):
-
Hi Troels,
When you believe the branch is ready to merge back to trunk, please
make a merge request on the mailing list. I would prefer to merge the
branches myself - due to inevitable conflicts and the difficulties of
resolving these. But I would merge only after carefully reviewing the
Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
I have a suggestion for this change too, specifically:
@@ -123,6 +129,8 @@
# The next lines calculate the R2eff using a two-point
approximation, i.e. assuming that the decay is mono-exponential.
Mx = fabs(Mint[1] / pA
Hi Troels,
This is close to the correct fix, but not quite right. The
'list_val_or_list_of_list_val' fits into the 2D sequence types
below. Have a look at what it does for the GUI - just search for user
functions with other 2D sequence types, and open those up. You will
probably need to modify
Hi Troels,
For this dx.map 'chi_surface' argument (maybe it should be
'chi2_surface' as it is chi^2), you can use the 'dim' argument to fix
this to 4 elements. That helps in the GUI as well as checking if the
user has input something with 4 elements.
Regards,
Edward
On 27 May 2014 18:47,
.
Best
Troels
2014-05-27 18:18 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Ah, the answer to that is simple - this model fails for high kex
values. Therefore the test_ns_cpmg_2site_3D_no_rex8() unit test
checking for high kex is meaningless. You are also pushing things far
too far
of the matrix_exponential() function. We have to just
accept this behaviour and let the model fail hard, as it should! The
nested looping can also be deleted, as it is only required to allow
the test_ns_cpmg_2site_3D_no_rex8() unit test to pass.
Regards,
Edward
On 27 May 2014 20:55, Edward d'Auvergne
Hi Troels,
There are still a few things to fix. For example the
Relax_disp.test_hansen_cpmg_data_missing_auto_analysis system test no
longer passes, and I'm not sure why. There is also the following:
- The target_function.relax_disp to lib.dispersion API
is 100% consistent. I.e. R2eff is
Hi Troels,
I'm not sure about the kex = 1e5 check. You have to be careful,
because a number of the analytic models - CR72 possibly included - are
not defined for such timescales (of course this is dependant on the
alpha scale, hence dw has an effect). So there are a series of models
where kex =
Hi,
I first thought that it might have been this test suite printout change:
r23360: http://article.gmane.org/gmane.science.nmr.relax.scm/21105
But now, with that last message, it's clear that it is these two to
the version.py module:
r23345:
Molecular dynamics by NMR data analysis
Copyright (C) 2001-2006 Edward d'Auvergne
Copyright (C) 2006-2014 the relax development team
But this new git-svn support:
relax repository checkout
None
Molecular dynamics by NMR data analysis
Copyright (C) 2001-2006 Edward d'Auvergne
Copyright (C) 2006-2014 the relax development team
But this new git-svn support
Hi,
I have before tried to change the standard parameters for pA and kex.
diff --git a/specific_analyses/relax_disp/parameter_object.py
b/specific_analyses/relax_disp/parameter_object.py
-self._add('pA', scope='spin', default=0.5, desc='The
population for state A', set='params',
Oh, that's right, the auto-analysis is using the default values if
grid_inc is set to None:
http://www.nmr-relax.com/api/3.2/auto_analyses.relax_disp-pysrc.html#Relax_disp.optimise
That's where the problem comes from!
Regards,
Edward
On 23 May 2014 09:33, Edward d'Auvergne edw...@nmr
-23 9:21 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
I just made another simplification for the git-svn version.py support:
r23366: http://article.gmane.org/gmane.science.nmr.relax.scm/21112
Once this issue is resolved, I'll look at releasing relax 3.2.1 with
all the recent bugfixes
Last Changed Rev: 23372
Last Changed Date: 2014-05-23 10:30:49 +0200 (Fri, 23 May 2014)
2014-05-23 10:42 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
Cheers. The change I made at r23366
(http://article.gmane.org/gmane.science.nmr.relax.scm/21112) however
replaces
GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
You might have to help me work this one out, as everything works for
me on all test systems. What exactly do you see? Can you run
individual tests:
$ ./relax -s Relax_disp.test_cpmg_synthetic_dx_map_points
How long do you wait? Does the test
Hi Troels,
If you think that this is important enough, I can release relax 3.2.1
as a major bugfix release in the next few days with the change. As
relax 3.2.0 was just released with the B14 models as a major new
feature (https://freecode.com/projects/nmr-relax/releases/363882), it
could be
Hi Troels,
Just for reference, this is how I would change your commit message for
the release documentation, as this can make my life easier if you do
this for me ;) I didn't do this for all your commits in the last
message for relax 3.2.0
(https://gna.org/forum/forum.php?forum_id=2461) because
Hi Troels,
For reference, do you have the B14 optimisation results for this
parameter set prior to the fix? This is just to see the difference
the change makes.
Cheers,
Edward
On 21 May 2014 20:36, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Wed May 21 20:36:36 2014
New Revision:
I can also see that the calculation 0.5 * arctan2(-zeta, Psi) is
happening twice, so you could speed this up by eliminating the
repetition.
Regards,
Edward
On 22 May 2014 09:50, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
For reference, do you have the B14 optimisation results
,
and the open way we have
handled the implementation, and for the B14 showing very promising
results for an analytical solution
to the numerical solutions, I would put +5 votes for a new-very-quick,
bug release.
Best
Troels
2014-05-22 9:12 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com
will really try to do this better.
Maybe I should re-read:
http://www.nmr-relax.com/manual/Format_commit_logs.html
http://wiki.nmr-relax.com/Format_commit_logs
Best
Troels
2014-05-22 9:43 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
Just for reference, this is how I would
...@nmr-relax.com wrote:
Hi Ed.
No, I just think that it is important to change these two lines.
I can do the optimisation in the speed branch.
Best
Troels
2014-05-22 10:07 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
A new point release now might take ~1 hour, or ~2 hours if you
.
Best
Troels
2014-05-22 9:50 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
For reference, do you have the B14 optimisation results for this
parameter set prior to the fix? This is just to see the difference
the change makes.
Cheers,
Edward
On 21 May 2014 20:36
Hi Troels,
Do you mean the unit tests of lib.dispersion rather than system tests?
For merging everything together, it might be better to add the unit
tests to the trunk. Or even better to your 'disp_speed' branch.
Otherwise you will not see these changes in the 'disp_speed' branch.
Regards,
It might be too difficult to synchronise the two branches, then manage
to merge them together (well one after the other) into the trunk.
Regards,
Edward
On 22 May 2014 10:58, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
Do you mean the unit tests of lib.dispersion rather than
system test right now in trunk, that I know will fail.
So, I will write them in disp_speed_compare.
Then I will try to see if I can import from disp_speed_compare to
disp_speed.
If not, I will just copy over manually and try it.
Best
Troels
2014-05-22 11:00 GMT+02:00 Edward d'Auvergne
You can see some details of this problem in the
devel_scripts/broken_branch_recovery.py script.
Regards,
Edward
On 22 May 2014 11:19, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
Commits cannot be migrated between branches, as that makes the merge
back to trunk a nightmare. This has
:20 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
You can see some details of this problem in the
devel_scripts/broken_branch_recovery.py script.
Regards,
Edward
On 22 May 2014 11:19, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
Commits cannot be migrated between branches
the release.
Cheers,
Edward
On 22 May 2014 13:21, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
I would recommend putting this one directly into your 'disp_speed'
branch. It's ok if the scope of a branch expands a bit. But it would
be best there as that is where you'll
is 1, or something similar.
This was what happened in:
https://gna.org/bugs/index.php?22032
bug #22032: Minimisation explodes when using Grid_INC=None
Best
Troels
2014-05-22 19:03 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
Now that the 'no Rex' unit tests for this LM63
These rather important changes might be a good reason to finish the
'disp_speed' branch quickly, so that I can merge it back to trunk and
then release relax 3.2.2 as a major bugfix release :)
Regards,
Edward
On 22 May 2014 19:15, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Thu May
this in the lib.dispersion modules. It is
the model itself which should model this correctly - and I know that
some cannot. If you use this test for the other models, you'll see
for yourself.
Regards,
Edward
On 22 May 2014 19:32, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hmmm, interesting. I might
Hi Troels,
With some of these, you have to be very careful that the parameter
combination actually does produce infinite R2eff values. I think in
this combination, it might not be the case. What input parameter
value causes weff2 to be zero? To properly check, one needs to take
the original
Hi Troels,
In this change, you are checking if:
kex^2 + spin_lock_fields^2 == 0.0
Here kex can be zero, but the spin-lock field should not be. Well, I
don't think so, but maybe the interpolated plotting does this. Do we
need a check added at all? Did you see a numpy warning? If not, such
if the other tests are necessary.
This one check might eliminate the need for most of the other checks
and the less checks there are, the faster the code will be.
Regards,
Edward
On 21 May 2014 08:37, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
With some of these, you have to be very
Hi Troels,
You are still mixing the two unrelated changes - the API change
(returning R2eff rather than filling in back_calc) and the math domain
error checking - into one commit. If you implement the check I
mentioned earlier
(http://www.mail-archive.com/relax-devel@gna.org/msg05731.html), then
Hi Troels,
Again the mixed API and math domain error checking commit is a problem
here. The reason is because you do not need to always check that the
denominator is zero. In many cases, it is impossible! The
denominator here is:
1.0 + omega_a^2 * tex^2
There is no way that adding a positive
Hi,
Again I don't think that the denominator can be zero. Did you see
this in the test suite?
Regards,
Edward
On 20 May 2014 22:29, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Tue May 20 22:29:52 2014
New Revision: 23277
URL: http://svn.gna.org/viewcvs/relax?rev=23277view=rev
Hi,
Before making the changes, I have some points. Especially about your point 1).
Thanks for all the suggestions for correcting the error cathing.
I am looking into it, and I am very happy that you catch my errors.
No problems. Code review is always useful! Pity no one sees all the
bugs
Hi Troels,
This change looks like it has introduced a bug. The R1_R2 value will
not be a numpy array matching the R2eff dimensions.
I have a suggestion to catch these types of problem. It's very simple
to implement too. Just add unit tests for all of the lib.dispersion
modules! Simply create
Hi Troels,
There is another bug here. Although it looks like you are dividing by
zero when kex is 0.0, what is happening is that you have 0.0 / 0.0 !
The result should not be Inf (or a big number). Do you have access to
symbolic maths software such as Maxima, Mathematica, etc.? You should
put
Hi,
Maybe this shouldn't be a bug? It's only present in your 'disp_speed'
branch and is only seen with a debugging flag turned on. If you add
the check I mentioned at
http://www.mail-archive.com/relax-devel@gna.org/msg05731.html to the
first line of this function, maybe all the checks you have
away! Especially in the numeric dispersion models.
And then many checks will no longer be necessary
(https://gna.org/bugs/?22065 and most errors you see in the test suite
with --numpy-raise will disappear).
Regards,
Edward
On 21 May 2014 08:48, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi
will become
redundant.
Regards,
Edward
On 21 May 2014 19:10, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
You should really consider adding this check to absolutely all
lib.dispersion modules. And as close to the first line as possible
(for most it should be on line one, even
Troels
2014-05-21 19:03 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
Maybe this shouldn't be a bug? It's only present in your 'disp_speed'
branch and is only seen with a debugging flag turned on. If you add
the check I mentioned at
http://www.mail-archive.com/relax-devel@gna.org
Hi Troels,
Once bug #22055 (https://gna.org/bugs/?22055) has been fixed, you will
have to revert this commit. This code is used in the other analysis
types, so it is rather fatal. It may not be visible in the test suite
though. The problem is elsewhere
Hi Troels,
For good repository management, you should try to keep separate ideas
in separate commits. In this commit you actually have two separate
concepts in one commit - the change of the target_functions.relax_disp
to lib.dispersion API, and handling of numpy.cosh() overflows. These
should
Hi Troels,
I was wondering if you have tried the following:
self.back_calc[0][si][mi][0] = r2eff
The last dimension of self.back_calc are the number of dispersion
points. This should match r2eff. Hence the line above will result in
a copy of r2eff placed into the self.back_calc numpy
Oh, forget about my previous comment
(http://www.mail-archive.com/relax-devel@gna.org/msg05715.html). This
change here is the problem - the original code should work just fine.
The problem with the processor.run_queue() method has nothing to do
with the specific analyses in relax
, and can fix it, I would be very happy.
I can try the thing you suggested, but beyond that, I would be lost.
Best
Trpels
2014-05-20 9:43 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
You might have actually have found the source of the problem! This
has been an issue for a long
Hi Troels,
Thanks for fixing the bug!
No problems.
But I think the worst most pity thing, is that I have waster 1/4-1/2
year of my PhD to fix this bug:
bug #22032: Minimisation explodes when using Grid_INC=None
https://gna.org/bugs/index.php?22032
I'm still trying to work out what this
fixed.
Best
Troels
2014-05-20 15:43 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
Thanks for fixing the bug!
No problems.
But I think the worst most pity thing, is that I have waster 1/4-1/2
year of my PhD to fix this bug:
bug #22032: Minimisation explodes when using
combinations to produce the same phi_ex value, and it
will be impossible to find the original values again. That is why
there are fast exchange models with the phi_ex parameter.
Regards,
Edward
On 20 May 2014 17:46, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
In this case, we need to perform
written it up as a task.
I will do it now.
My supervisor has also asked for this feature.
best
Troels
2014-05-20 18:56 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
In your testing, for sanity you may also want to look at calculating
the alpha value from:
- Millet
Hi Troels,
Maybe the proper way to solve this is for the det_arch() method to
create a simple 'hello world' C program, dump it in a temporary
directory, try to compile it with the different -arch flags, and then
see if a binary was created. As the current test shows that all 3
architectures are
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
Hi Troels,
When making such important changes, for debugging you should try
running the test suite as:
$ ./relax -s Relax_disp --numpy-raise
Echoing of user function calls has been enabled.
=
= System / functional tests =
=
Hi Troels,
For even faster code , have a look at:
https://stackoverflow.com/questions/6431973/how-to-copy-data-from-a-numpy-array-to-another
Regards,
Edward
On 19 May 2014 00:51, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Mon May 19 00:51:18 2014
New Revision: 23219
URL:
Hi Troels,
There is actually a better way that is just as fast. That is to catch
the value prior to the divide by zero, or what ever operation creates
the Inf values. Then you can fill back_calc with 1e100 and return.
That way the test will pass when running with --numpy-raise, and the
user
Hi Troels,
Here again you can avoid the divide by zero problems by having:
from numpy import max, abs
if min(abs(denom)) == 0:
back_calc[:] = array([1e100]*num_points)
Then these tests should then pass when running with --numpy-raise.
You should also not see any significant speed changes
Hi Troels,
In this case, do we even need the isfinite() check? Can this equation
ever calculate R2eff to be Inf? The only case I can think of is when
kex is 0.0, as rex = phi_ex/kex. Therefore you could replace this
check with:
if kex == 0.0:
back_calc[:] = array([1e100]*num_points)
Hi Troels,
Again for this dispersion function, you can use the zero 'denom' check
to avoid all numpy warnings
(http://thread.gmane.org/gmane.science.nmr.relax.scm/20966).
Regards,
Edward
On 19 May 2014 03:20, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Mon May 19 03:20:43 2014
New
Hi Troels,
This one will be much harder to properly catch all numpy errors.
However you could try something like:
from numpy import abs, max
if max(abs(etapos)) 200:
back_calc[:] = array([1e100]*num_points)
return
This might be sufficient to replace your isfinite() block.
Regards,
Hi,
The matrix_exponential() and square_matrix_power() functions are the
problem. If an equivalent for an array of matrices could be designed,
it could be added as a new function to
lib.linear_algebra.matrix_exponential and
lib.linear_algebra.matrix_power. This is a difficult problem.
Regards,
to relax_fit.so being a wrong architecture.
I cannot do ppc.
Best
Trpeæs
2014-05-19 9:34 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
Maybe the proper way to solve this is for the det_arch() method to
create a simple 'hello world' C program, dump it in a temporary
directory, try
is not consistent
and designed correct.
Best
Troels
2014-05-19 9:53 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
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
=old_settings['under'])
print back to normal
print np.seterr()
2014-05-19 10:02 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
When making such important changes, for debugging you should try
running the test suite as:
$ ./relax -s Relax_disp --numpy-raise
Echoing of user
be, that in 95 percent of the time, the minimise function is
just happy and calculating.
Only at boundaries values, the math domain errors can get triggered.
Rather that 5% of the time, it calculates to much, that 95% is full of
checking.
Best
Troels
2014-05-19 10:18 GMT+02:00 Edward
generated.
2014-05-19 11:01 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
Could you try creating the hello.c file with:
#includestdio.h
main() {
printf(Hello world\n);
}
Then type:
$ gcc -arch ppc hello.c -o hello
$ ./hello
What does this show on your system? Does
Hi Troels,
I have one suggestion here. The following check is not necessary:
if num_points 0:
This will slow down the code. Note that this situation should never,
ever be reached. If it is, then we are doing something wrong in the
specific_analyses.relax_disp package prior to passing the
Hi Troels,
Would you like to look after this bug? It was introduced with your
commit r23078 (http://article.gmane.org/gmane.science.nmr.relax.scm/20820),
and this is a blocker for releasing relax 3.2.0. You will need to add
support for the 'list_val_or_list_of_list_val' py_type to the
,
Edward
On 12 May 2014 10:21, Edward d'Auvergne e...@nmr.mpibpc.mpg.de wrote:
Great! This should finally kill these incredibly annoying spam bots!
This 'Trusted' access level is perfect. As this will be a low traffic
wiki, we should never be overwhelmed by users asking to be in the
'Trusted
troels
2014-03-25 14:33 GMT+01:00 Edward d'Auvergne e...@nmr.mpibpc.mpg.de:
Hi Troels,
In case you missed it, I have been deleting a number of spam bots from the
wiki:
http://wiki.nmr-relax.com/index.php?title=Special:RecentChangesfrom=2014032400
Somehow the new CAPTCHA method
(http
Hi,
This bug has something to do with setting metadata for spectral
information from two field strengths, but only loading data from one.
In such a case, you will need to very carefully check the data that
the user has input, and complain hard with a RelaxError if something
is wrong. See
Hi Troels,
This is a great idea! But it is rather disruptive. Therefore I have
some suggestions below. Rather than answering all in one post, for a
nicer thread structure at
http://thread.gmane.org/gmane.science.nmr.relax.devel/5747, it is good
to answer each point below in a separate post.
Wait, Troels, the problem here is not that the number is close to
infinity. It is that numpy.cosh() can't handle numbers 100! Try
running:
from numpy import cosh
for i in range(10):
print(cosh(%i+0.0j): %s % (i*100, cosh(i*100+0.j)))
You will see:
cosh(0+0.0j): (1+0j)
Hi Troels,
This will do the trick! I would suggest that this module be shifted
into the 'extern' package. This is a special package for external
software or code that is bundled with relax, when the licence so
allows, so this numpy code will fit in quite well there. If you go
back into relax's
I really think for my case, that 25 speed up is a deal breaker !
I have so much data to crunch, that 25 speed is absolutely perfect.
Note that with the CR72 model, there are still a number of
optimisations which can be performed which will probably give a lot
more speed than this 25%. In
.
Best
Troels
2014-05-09 14:58 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
This approach can add a little speed. You really need to stress test
and have profile timings to understand. You should also try different
Python versions (2 and 3) because each implementation is different
Hi,
This post is a placeholder for ideas about how to optimise the
handling of the self.missing data structure in the
target_functions.relax_disp module. The current implementation is
very slow and has a significant impact on the speed of a dispersion
analysis.
The current logic is:
# Loop
of the math domain.
I will make a return in the library function, and then updating the
class object:
Best
troels
2014-05-09 16:07 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
That might work - but it will require testing. I really don't know
what will happen. The current test suite
Great idea! I say that because I had a similar idea all the way back
in 2004/2005 when I wrote this code ;) Some additional points:
- I also had the idea of letting the user set these themselves,
through a user function argument (a list of number with 4 dimensions).
This can be useful in
Hi Troels,
A better way to handle this would be to pass in an array of 4 values
for the isosurface levels into write_program(). Then you can change
these values as needed in pipe_control.opendx and not have to worry
about what happens in lib.software.opendx ever again. It would
decouple the
))
self.contour_levels.append(percentile(all_chi2, 10))
This might work better with OpenDX.
Regards,
Edward
On 9 May 2014 18:08, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
A better way to handle this would be to pass in an array of 4 values
for the isosurface levels into write_program
Here is a demo:
from numpy import array, float64, percentile
a = array(range(11), float64)
print(percentile(a, 90))
print(percentile(a, 50))
print(percentile(a, 20))
print(percentile(a, 10))
Regards,
Edward
On 9 May 2014 18:14, Edward d'Auvergne edw...@nmr-relax.com wrote:
You may
Hi,
Could you revert this? Because of licencing, we unfortunately cannot
use this code from
http://code.activestate.com/recipes/511478-finding-the-percentile-of-the-values/.
Also, a percentile() function would go into lib.statistics rather
than lib.mathematics.
Cheers,
Edward
On 9 May 2014
Hi Troels,
We are now seeing some nasty spam behaviour on the wiki! This spam
bot just added a random link inside the
http://wiki.nmr-relax.com/Tutorial_for_adding_relaxation_dispersion_models_to_relax
article!! I'll clean it up.
Regards,
Edward
-- Forwarded message --
10:24, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
Hi Edward.
Maybe we should make it like the pymolwiki.
http://www.pymolwiki.org:/index.php/Main_Page
There you have to write to Jason, to be made a user.
Best
Troels
2014-05-08 9:34 GMT+02:00 Edward d'Auvergne edw...@nmr
801 - 900 of 2509 matches
Mail list logo
