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 - Andreas Brinkmann

Pages: [1]
1
This is not really a bug, but under non-ideal conditions (large Hamiltonians, non-sufficient accuracy settings), the numerically calculated eigenvalues wrsk in the COMPUTE routine can have a small but significant imaginary part. This can translate to peak frequencies that have an imaginary part if the DigitalFrequencyResolution->True setting fails to "snap" the peak frequency to the frequency grid. In that case the FT might fail.

I would recommend taking Re[wrsk] of the eigenvalues and/or print a warning if the imaginary part is significant.

Please see attached your RotationalResonance.nb Example, that I forced into the above behavior.

2
Bug reports / Re: More of a question: Ordering of Zeeman product states
« on: February 06, 2015, 07:21:28 PM »
Thanks a lot Malcolm. I guess I am getting picky here, but your "more complex case" has some odd behavior in how the ReorderedKets look: Originally, you have a spin system {{1, 1}, {2, 1/2}, {3, 3/2}}, so before the reordering a product ket looks like |1 +1, 1/2 +1/2, 3/2 +3/2>. After reordering, a reordered ket looks like |1/2 +1/2, 3/2 +3/2, 1 +1>. I see that the reordered product kets itself are in the right order, i.e. the next one is 3/2 +1/2, but it's still odd that the spin order seems now 2, 3, 1. The input into the Outer[] function looks fine, so I guess this must happen in the ProductKet[] routine.

Andreas

3
Bug reports / Re: More of a question: Ordering of Zeeman product states
« on: February 06, 2015, 03:43:14 PM »
Sorry, wanted to add a snapshot:



Andreas

4
Bug reports / Re: More of a question: Ordering of Zeeman product states
« on: February 06, 2015, 03:33:23 PM »
Hi Malcolm,

thank you for your answer. Your approach using SpinPermutationOperator[] works fine for a system of spins with the same spin quantum number.

However, I first noticed the different ordering of basis states when I looked at a spin system of a spin-1 and spin-1/2 (SetSpinSystem[{{1, 1}, {2, 1/2}}]). In this case SpinPermutationOperator[] does not work, since I get the error that the spin cannot be exchanged since they have different spin quantum numbers.

Currently, I am using the approach SetSpinSystem[{{2, 1/2}, {1, 1}}], where I reversed the order of the spins together with the labels, so for example I1x still refers to the spin-1.

Andreas

5
Bug reports / More of a question: Ordering of Zeeman product states
« on: January 29, 2015, 08:45:18 PM »
Hi,

I noticed that in SpinDynamica the Zeeman product states for example for a 2 spin 1/2 system per default are ordered as {|αα>, |βα>, |αβ>, |ββ>}. However, in the literature (e.g. spin dynamics) and other calculation programs (Simpson, mPackages) the order is {|αα>, |αβ>, |βα>, |ββ>}.

As a result, one has to be very careful when transferring a matrix representation from SpinDynamica for example to Simpson.

Is there a flag to switch the way the product states are generated?

Andreas




6
Feature requests / Launch remote kernels in PrepareParallel
« on: September 26, 2013, 07:58:40 PM »
Currently, PrepareParallel launches local kernels only. It's relatively easy to setup remote kernels under "Preferences->Parallel->Remote Kernels", however they would not be started with simply LaunchKernels[number]. For demonstration, I added a simple option Parallel->AllConfigured to PrepareParallel that will launch all configured kernels, both local and remote:
Code: [Select]
MatchQ[parallel, AllConfigured],
(Message[PrepareParallel::allconfigured];
  CloseKernels[];
  Scan[LaunchKernels, $ConfiguredKernels]),
Here, I don't try to do any kernel bookkeeping, so I just close the current ones and launch all configured ones as new. Ideally, one could imagine some fancy bookkeeping where for a certain number of requested kernels, first local kernels are started, then remote kernels and at the end additional local kernels.

7
Bug reports / proton magnetogyric ratio typo!
« on: June 14, 2013, 09:46:19 PM »
Dear all,

there is a typo in the magnetogyric ratio of 1H:

26.75522128e7 instead of 26.7522128e7

Please correct, it took me a while to discover this small inconsistency of newer SpinDynamica versions to older ones.

Andreas

8
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: June 14, 2013, 03:37:26 PM »
Hi Malcolm,

this problem occurs both for Parallel->True and Parallel->False. If I specify a Preparation sequence, it does not occur for the calculation of that one, but only for the Compute part. I notice that in the code of Compute the call to NPropagationOperator[] does not pass any additional options? Should I better open a new thread since this is more Compute related than a parallel problem?

Andreas

9
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: June 13, 2013, 09:00:02 PM »
One thing I noticed though:

If I use Signal1D[..., MaxSteps->xxx] the option is not passed on to NDSolve[]. I am using SignalCalculationMethod -> "COMPUTE" in this example.

Andreas

10
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: June 13, 2013, 07:04:15 PM »
Dear all,

I tested SDv2.6.2b2 and it works great for me (I am using mainly Signal1D). Thanks Jyrki!

Andreas

11
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: May 09, 2013, 07:37:28 PM »
Hi Jyrki,

I had done some extensive testing when Malcolm implemented the parallelization into SpinDynamica. Prerequisite were (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.

To summarize my findings please have a close look at the attached notebooks, I tried to document them well. They cover all the suggestions by you and Michael that I also had tested earlier. None of the suggestions utilizing $Path on the subkernels work in general. As you can see the main problem occurs when new subkernels are added to existing ones (or relaunched after closing). I am not sure why that is exactly, since it should in principle work, as we all agree. There also seems to be a subtle difference between ParallelNeeds[] and ParallelEvaluate[Needs[]] in spite of the documentation saying that they should be identical.

As a result I had to conclude that currently the only straightforward and simple solution for users is to specify the $Path in init.m. This works flawlessly in all cases (see first attached notebook). Therefore, I still think this is so far the only solution that works in general.

Andreas

12
Bug reports / Re: Parallel computing using SpinDynamica 2.6.0
« on: May 07, 2013, 04:10:01 PM »
Dear all,

I had considered a solution similar to the suggestion by Jyrki and Michael, however there is a problem with this solution when changing the number of kernels in a series of calculations. We had an example notebook (see attachments) that would use (for example on a 4 core machine) Parallel->False, Parallel->2, Parallel->True, ... The suggested approach fails when the number of kernels used is increased from one calculation to the next.

The reason is that DistributeDefinitions and ParallelNeeds will automatically be evaluated on a newly launched subkernel, however ParallelNeeds is evaluated before DistributeDefinitions. Hence, in this case the $Path would not be set correctly.

The only solution I could find is to add the $Path to the init.m file (as Malcolm described) and change the launching of the subkernels so that each reads the init.m file.

Please have a look at the attached files and see if you have another general solution. Otherwise I would suggest that the $Path in general should be specified in init.m.

All the best,

Andreas


13
Feature requests / ZCW6044 and simple parallelization of Signal1D
« on: October 01, 2012, 09:53:47 PM »
Dear all,

please find here

http://dl.dropbox.com/u/37396198/SDv2.5.3-Parallel.zip

a modified version of SDv2.5.3 that provides both 6044 ZCW powder angles (OrientationalSampling.nb) and a relative simple parallelization of the Signal1D routine when an ensemble average is performed (SpinDynamics.nb).

The RotationalResonance example demonstrates how to use the parallel version. It also shows that there is some (serial) overhead in the Signal1D routine, I have added some comments in the code of SpinDynamics.nb to indicate where I used Mathematica's Parallel... routines and which steps are not scaling nicely.

All the best,

Andreas

Pages: [1]