Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - MalcolmHLevitt

Pages: 1 ... 4 5 [6] 7 8
Bug reports / Re: Timing test for SDv2.6.1
« on: June 10, 2013, 06:07:21 PM »
My documentation shows that at v2.5.2 I fixed a bug in CombineTrajectories which was leading to extremely slow calculations, and then fixed another bug in the same routine at v2.5.4, and again for v2.6b2. As I recall, I was seeing mysterious overshoots in the trajectory. I traced these to the FunctionInterpolation function of Mathematica, which I found to be unreliable. So I recoded to avoid FunctionInterpolation, but the efficiency of the code seems to have been compromised at the same time. I tend not to use so many time intervals, so I must have missed its poor efficiency in that case.

Unfortunately I am reluctant to open that can of worms again, given my current commitments.

If anyone volunteers to look at this, I have on file the test notebooks that I used to fix the bugs mentioned above.

If I recall, the line mentioned above:
Code: [Select]
\[Rho]intervalfuncs = Function[t,Evaluate[Assuming[(First[#] < t < Last[#]), Refine[\[Rho]func[t]]]]]& /@tintervals;Has the following purpose.
tintervals contains the set of time intervals for the Piecewise function, i.e. {..,{tb,ta}}
\[Rho]func is the Piecewise function for the density operator Rho, which may be evaluated at any time over the whole trajectory
\[Rho]intervalfuncs is the set of functions for Rho, which apply for the individual intervals, i.e. {..Rhofunc2, Rhofunc1}.
I obtain these from Rhofunc by using Refine and Assuming. This has the benefit of reliability and generality. I found this method to be convenient but there might well be a more efficient method.

Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: May 14, 2013, 02:33:46 PM »
Hi all,
 thanks so much for all the blood, sweat and tears!

 I'm just catching up on the discussion. However I am wondering what the state of play is now. I concur with Andreas that the most desirable solution should have the features

(i) SpinDynamica handles launching and closing of subkernels, not the user, (ii) subsequent calculations may change the number of subkernels used, and (iii) specifying the location of the SpinDynamica package by the user should be done in a single place for simplicity.

I would also very much like to have as much as possible of the parallel code inside a routine of the form PrepareParallel[..] and not in the individual routines. Some of the suggestions above seem to propose more complex solutions to the observed glitches, but I think that making the code for the individual routines even more complicated is asking for trouble when the routines are developed further.

Please work with the new version 2.6.1 which has been released on the SD website.

Can one of you (Andreas?) volunteer to generate a new version 2.6.2b1 by copying 2.6.1 and which includes the proposed Parallel modifications, and distribute it with a test notebook? Or are we not yet at the stage to try that?

I'm off to Brazil today but I hope to have time to help over the next 2 weeks

all the best malcolm

Updates and Messages / SpinDynamica 2.6.1
« on: April 28, 2013, 04:46:51 PM »
SpinDynamica 2.6.1 has now been released on

Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: April 28, 2013, 04:44:10 PM »
SpinDynamica 2.6.1 has been released and includes a fix for this bug. Please let me know if the problem persists in your installation.

A bug fix has been included in SDv2.6.1 which has now been released.

Bug reports / Re: Composite operator basis
« on: March 29, 2013, 01:27:52 PM »
 I am trying to reproduce this bug in v2.6.0 but I do not find the abnormal behaviour. Maybe it has somehow fixed itself. Can you try to reproduce the bug and provide an example notebook if it persists?

This is indeed a disturbing bug, and it is still there in 2.6.0.

I have fixed the problem. The next release 2.6.1 will not experience this bug.

Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: March 29, 2013, 01:12:42 PM »
Another question:
There is a warning in /NMR/SpinDynamics.nb (see section "Parallel") that basis transformation matrices should be freshly evaluated.  I assume this means that SpinDynamica otherwise calculates the matrices across all kernels.  Is that correct?

On this subject I remember a while ago that we discussed "hard coding" matrices into SpinDynamica for common bases and basis transformations, so that these may be loaded from definitions as opposed to being calculated on-the-fly.  Maybe there is scope for that in future releases.

Thanks Michael and Jyrki,
 Maybe I do not see the $Path errors because I set the path in the init.m file of my Autoload directory. When the new kernels are launched they probably all use the same init.m. In the next release I will modify the PrepareParallel routine to ensure that $Path is set correctly in all the running kernels, even if this procedure is not used.
 Some tests I use for the parallelization are attached.
 SpinDynamica currently does remember and reuse all calculations of basis transformation matrices, so I think your last point is already taken care of.
all the best

Feature requests / Re: ZCW6044 and simple parallelization of Signal1D
« on: March 26, 2013, 09:27:13 AM »
ZCW6044 orientational sampling, and parallelization of EnsembleAverage, are now included in SDv2.6.0

Bug reports / Re: Needs["Rotations`OrientationalSampling`"] (SD 2.5.5)
« on: March 25, 2013, 12:05:52 PM »
Thanks Michael,
 the message appears when the package "Rotations`OrientationalSampling`" is loaded and added to $Path. When Needs[..] is executed again, Mathematica looks to see if the package is already on $Path (and therefore loaded), and does not load again if it is there. So there is no way to force Needs[..] to regenerate the message a second time, without redefining the built-in Needs function, which might have unintended consequences, and is inadvisable. So there is no straight workaround for this.

However, as you discovered, executing or Orientations[] or OrientationsAndWeights[] will list the available orientational sampling schemes.

Updates and Messages / SpinDynamica 2.6.0
« on: March 18, 2013, 09:58:46 PM »
SpinDynamica 2.6.0 has been released here:

  • bug fixes and speed enhancements
  • parallel computing of EnsembleAverage

The parallelization of EnsembleAverage is implemented by default. It may be disabled by using the option Parallel->False. Numerical values such as Parallel->n implement the computation by distributing over n parallel kernels. The default Parallel->True distributes over all available parallel kernels.

Thanks to Andreas Brinkmann for help with the parallelization.

Examples / Re: Ernst angle
« on: February 20, 2013, 12:18:56 PM »
Hi Michael, thanks for this -
 - however please repost using the standard input Needs["SpinDynamica`"], otherwise your .nb will not run. I would also request that you use standard LeftToRight chronology..
 all the best

Examples / Re: Spin 1 quadrupolar powder patterns
« on: January 11, 2013, 05:13:55 PM »
Hi 1K, no, this is not correct. In the secular limit (interaction with static field much larger than the quadrupolar Hamiltonian) then the m !=0 components of the spin operators are suppressed. See pages 185 and 190 of SpinDynamics 2nd edition. The presence of biaxiality (eta!=0) has nothing to do with this. In the example notebook, biaxiality is simulated by including m!=0 components of the spatial part of the interaction (not the spin part).

You're correct that the zero-field form of the quadrupolar interaction would include all combinations of spin and space tensor components (see page 614). However, in high magnetic field, the interaction with the main field suppresses the influence of the T2-1, T2-2, T21 and T22 terms. If these were included, the simulation concerns zero-field NMR of quadrupolar nuclei (also known as NQR).

Examples / Spin 1 quadrupolar powder patterns
« on: December 20, 2012, 02:36:34 PM »
This notebook (which uses v2.5.5) shows how to calculate spin-1 powder patterns, including biaxiality (often referred to as "asymmetry").

Bug reports / Multiplying operators (a trap for the unwary)
« on: December 18, 2012, 02:12:36 PM »
Unexpected behaviour (including getting stuck) has been reported by users who attempt to multiply two operators using Times rather than Dot, i.e.

opI[1,"x"]*opI[2,"z"]  (incorrect)

rather than

opI[1,"x"].opI[2,"z"] (correct)

using Times ("*") for operators is illegal. Always use Dot (".") to multiply operators (and vectors, for that matter).

Times may however be used to multiply operators by numbers, for example

2 Pi * opI[1,"x"] (correct)  or
2 Pi opI[1,"x"].opI[2,"z"] (correct)

Pages: 1 ... 4 5 [6] 7 8