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 - MichaelTayler

Pages: [1]
1
Thanks Malcolm,
Yes, that is probably too much unnecessary poking around.  A note in SD's documentation on OrientationsAndWeights should be enough.

2
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: May 12, 2013, 09:28:12 PM »
Jyrki, yes, with 2.6.0 I have had difficulties with parallelised calculations involving non-default $Chronology "RightToLeft"; I prefer to specify events with "RightToLeft" chronology but usually find that the subkernel still evaluates with the default chronology!

At present I am happy to launch by opening all available kernels, distributing the path, then loading SpinDynamica with Needs.  It appears that all definitions such as Basis[], $Chronology etc. are good and consistent across the kernel and subkernels, without any need for explicit distribution. 

Here is what I use:
1) Define my path for SpinDynamica
Code: [Select]
sdPath = ToString[$InstallationDirectory <> "\\SpinDynamica\\SpinDynamica260\\"];
SetSharedVariable[sdPath]

2) Add SpinDynamica path to $Path of both kernel and subkernels (BOTH are required)
Code: [Select]
ParallelEvaluate[AppendTo[$Path, sdPath]];
AppendTo[$Path, sdPath]

3) Load SpinDynamica
Code: [Select]
Needs["SpinDynamica`"]
The above all works fine in 2.6.0 and I can see no bugs or misevaluation with $Chronology or similar global options.  The solution is probably not general enough for solving Andreas's problem, however.

3
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: March 28, 2013, 12:39:41 AM »
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.

4
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: March 28, 2013, 12:24:49 AM »
Hi Jyrki,
Great.  That seems to do the job.  The routines evaluate in parallel after replacing

Code: [Select]
path = AppendTo[$Path, (*insert path here*)];
Needs["SpinDynamica`"]

with

Code: [Select]
LaunchKernels[];
path = AppendTo[$Path, (*insert path here*)];
DistributeDefinitions[path];
ParallelEvaluate[$Path = path];
Needs["SpinDynamica`"]

5
Bug reports / Parallel computing using SpinDynamica 2.6.0
« on: March 27, 2013, 01:28:26 PM »
I am having some difficulty using "parallelization" in v. 2.6.0, which I think is due to an incorrect loading of the packages.  I am loading SpinDynamica in the standard way via

Code: [Select]
AppendTo[$Path, (*insert path to 2.6.0 here*) ]
Needs["SpinDynamica`"]

The error messages below arise when running Signal1D, Trajectory and similar routines: (repeated 8 times, once for each of 8 Kernels launched)

Code: [Select]
Get::noopen: Cannot open SpinDynamica`.
Needs::nocont: Context SpinDynamica` was not created when Needs was evaluated.

Any guidance is much appreciated!  It would be very useful for someone to upload an example file for a "working" parallel calculation

6
General Discussion / Spin dynamics T-shirt
« on: March 06, 2013, 12:55:32 PM »
For those of you who may be interested:

http://shop.yoyoexpert.com/product/669/Spin-Dynamics-T-Shirt

7
Examples / Re: Ernst angle
« on: February 20, 2013, 12:33:08 PM »
Hi Malcolm,
OK, revised file re-upped in the original post.  This now obeys the standard "Needs" input and LeftToRight chronology. 
If this is ok, we can delete these replies.
M.

8
Examples / Ernst angle
« on: February 20, 2013, 10:44:54 AM »
The attached notebook illustrates the "Ernst angle", which is the flip angle that maximizes steady state transverse magnetization for a given recovery delay between successive scans in an NMR experiment.   (Output has been stripped due to strict file upload size on this forum)



The Ernst angle is close to 90 degrees if the delay between scans allows near-complete longitudinal recovery, i.e. is a few times T1.

For a recovery delay that is short compared to T1, the Ernst angle is substantially less than 90 degrees.


9
Bug reports / $Chronology LeftToRight and RightToLeft
« on: February 14, 2013, 12:27:40 PM »
Just a quick note that while SpinDynamica's current default chronology is LeftToRight, most of the "Illustrative NMR" example files are written with chronology RightToLeft and therefore do not execute correctly.

10
Bug reports / Needs["Rotations`OrientationalSampling`"] (SD 2.5.5)
« on: February 05, 2013, 12:11:57 PM »
When loading the sub-package OrientationsAndWeights there appears a very helpful message stating the in-built sampling sets that one can use:

Code: [Select]
Needs["Rotations`OrientationalSampling`"]

However, if one executes the above code again, the message disappears and it cannot be recovered (as far as I know) without restarting Mathematica's Kernel. 

While the list of available sampling schemes can still be obtained using

Code: [Select]
Orientations[]
it would be nice to make the message with "Needs" permanent.

11
It appears that there is a bug with ExpressOperator handling ShiftAndPolarizationOperatorBasis in SD 2.55.  The result after evaluating

Code: [Select]
SetSpinSystem[1];
ExpressOperator[
 opI[1, "\[Alpha]"],
 ShiftAndPolarizationOperatorBasis[]
]

gives an operator with norm Sqrt[2], whereas the correct norm is 1.  For the following cases, however, everything works as expected, i.e. the operator norm is preserved:

Code: [Select]
ExpressOperator[
 opI[1, "z"],
 CartesianProductOperatorBasis[]
]

and

Code: [Select]
ExpressOperator[
 opI[1, "\[Alpha]"],
 CartesianProductOperatorBasis[]
]

12
Bug reports / Re: Composite operator basis
« on: January 16, 2013, 01:48:02 PM »
Update: it appears that SpinDynamica cannot handle the outer products this way.  There is a workaround, however.  I'll publish the code shortly.

13
Bug reports / Composite operator basis
« on: January 16, 2013, 09:07:18 AM »
Hi everyone,
This is a post about constructing operator bases, and some problems that I'm experiencing.  I'm using SpinDynamica 2.5.5.

I would like to set an operator basis by multiplying together basis operators of two or more spin systems.


Suppose that I have two systems, {{1,1/2},{2,1/2}} and {{3,1/2}}. 
I'd like to make an operator basis for the whole system {{1,1/2},{2,1/2},{3,1/2}} as follows:

SetSpinSystem[{{1,1/2},{2,1/2},{3,1/2}}]
basisops12=BasisOperators[CartesianProductOperatorBasis[{{1,1/2},{2,1/2}}]]
basisops3=BasisOperators[ShiftAndZOperatorBasis[{{3,1/2}}]]

(* the operator bases for {1,2} and {3} are arbitrary, but cannot be ZeemanKetBraOperatorBasis *)

basisops123=Flatten@Outer[Dot[#1,#2]&,basisops12,basisops3]

DefineOperatorBasis[basis123,basisops123]
SetOperatorBasis[basis123]


Now, up until this point it appears there are no problems.  I find that executing BasisOperators[] gives an output equal to basisops123.  CheckOperatorBasis[] outputs True.  OperatorQ applied to any of the basis operators also gives True.

However, there are serious problems when using the basis to represent superoperators.  Routines ExpressOperator, OperatorVectorRepresentation or SuperoperatorMatrixRepresentation all fail with some error message about incommensurate basis dimensions when multiplying matrices within SpinDynamica's internal workings.  Any ideas on what is at fault or where a solution may lie?

14
Hi Ronghui,

There is a neat trick for this, which is used internally in SpinDynamica.  If the density matrix is represented in the Zeeman ket-bra basis, it can be flattened to a vector corresponding to the coefficients of the Zeeman ket-bra operators.  One can then take the dot product with the appropriately-ordered list of basis operators.

To solve your problem in SpinDynamica you can use the ExpressOperator routine, which works more-or-less in the way that Ilya (kuprov) has described:

Code: [Select]
op=opI[1].opI[2]

ExpressOperator[
op,ZeemanKetBraOperatorBasis[]
]

For more information you can look up the help message by executing

Code: [Select]
?ExpressOperator

Pages: [1]