Error: too many gamma angles to average

[Chitrak]

Hi,

I am getting this strange error message when I am trying to run a SPINEVOLUTION code. It keeps saying "too many gamma angles to average". I am using zcw233 powder averaging and 16 gamma angles. Could you help me get rid of this?


Thanks,
Chitrak.

[Mikhail Veshtort]

Dear Chitrak,

I hope you resolved this issue yourself by now. Sorry I didn't answer your question earlier...

This error message appears most likely because you didn't take care to rotor-synchronize your pulse sequence -- see Eq.(37) in the SPINEVOLUTION JMR paper. The n_gamma line in the input file specifies only the minimal number of gamma-angles for powder averaging. The actual number of gamma-angles must be greater or equal to the number n in that rotor-synchronization equation.

I would appreciate it if you sent me (to my personal email) the input file that was giving this error message as I didn't expect it to ever appear and I would like to correct it.

Best regards,
Mikhail

[Paul]

Dear Mikhail,

Posting on behalf of Chitrak, the simulation file is as follows:

****** The System ***********************************

spectrometer(MHz)  499.8

spinning_freq(kHz) 11.241

channels           C13 H1 N15

nuclei             C13 N15 H1

atomic_coords      CONHtrans.cor

cs_isotropic       *

csa_parameters     1 100 0.03 0 0 0 ppm

j_coupling         *

quadrupole         *

dip_switchboard    *

csa_switchboard    *

exchange_nuclei    *

bond_len_nuclei    * 

bond_ang_nuclei    *

tors_ang_nuclei    *

groups_nuclei      *

******* Pulse Sequence ******************************

CHN 1

timing(usec)    (11.12)100x18     1000    2.5  (r1425.pp)100x14

power(kHz)       0     90 100 *

phase(deg)       0     0 90 *

freq_offs(kHz)   0     0        0 *

CHN 2

timing(usec)    (r1817.pp)     1000    2.5   (28.56)

power(kHz)       *           0       0       0

phase(deg)       *           0 0 0

freq_offs(kHz)   *           0 0 0

CHN 3

timing(usec)    (11.12)       1000 2.5   (28.56)

power(kHz)       0         80 0 0

phase(deg)       0           0 0 0

freq_offs(kHz)   0           0 0 0

******* Variables ************************************

taur=1000/spinning_freq

******* Options *************************************

rho0               I3x I2x 

observables        I1z

EulerAngles        zcw233

n_gamma            16

line_broaden(Hz)   *

zerofill           *

FFT_dimensions     *

options            -nm_max1000000 -m0

******************************************************

*** I keep te Nitro freq at 0 ppm instead of 121 ppm

I have tried to break the rotor synchronisation condition using -nm_max1000000

The pulse sequence files are:

r1817.pp

5.56 90 70 0

5.56 90 110 0 

r1425.pp

14.28 35 64.3 0

14.28 35 -64.3 0 

Any help would be highly appreciated

Thanks

Paul

[Mikhail Veshtort]

Dear Paul and Chitrak,

Your sequence is indeed not properly rotor-synchronized. SpinEvolution requires that all D1 and D2 elementary pulse sequences must be rotor-syncronized. Only D0 sequences can be of arbitrary length. In your case, this means that sequences 1 and 3 (which are sampled in D1) must be rotor-synchronized. While sequence 1 is indeed rotor-synchronized (n=8, m=1), sequence 3 is not. It appears though that that sequence 3 is rather close to the (n=3, m=1) condition: the ratio of the rotor period to the length of this sequence is about 3.1.

If this is a mistake you made when setting up your pulse sequence, it has to be corrected but putting in the correct values of the pulse lengths and/or the spinning frequency. But if this is indeed what you intended then the only way to simulate this experiment would be by setting up sequences 1 and 3 as D0 and performing a parameter scan over their group size. In other words, you would need to change the timing line to

timing(usec)    (11.12)     1000      2.5    (r1425.pp)

and add the following to the Variables section:

scan_par n/0:99/

gsize_1=n*18

gsize_3=n*14

And this will be a very slow simulation, of course.

If, instead of this, one tries to force the rotor-synchronization by just setting a very large value for nm_max (and still sampling sequences 1 and 3 in D1, as in your original input file), it will lead to the (n=190, m=61) synchronization condition and will cause the program to complain about "too many angles".

I should only add that the reason SpinEvolution doesn't deal well with non-rotor-synchronized pulse sequences in D1 or D2 is a good one. If the pulse sequence is not rotor-synchronized, then the Hamiltonian during this sequence is not periodic. And if it is not periodic, then how does one know what to expect from this kind of experiment (except through numerical simulations)? Nevertheless, I realize that this functionality would be desirable for the generality of SpinEvolution, and so I hope to implement it some day soon...

Best regards,

Mikhail

--
You received this message because you are subscribed to the Google Groups "spinev-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spinev-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.