Anisotropic g tensor

[juho.roukala]

This might be something I don't understand, but using garlic in EasySpin 5.1.5: if I use an isotropic g value (with the necessary A, Sys, Exp data), or [gxx gyy gzz], I can more or less get a spectrum that matches experiment - so I know that technically everything is all right. However, if I instead give the full g tensor, in the simplest possible case just [gxx 0 0; 0 gyy 0; 0 0 gzz] which should be equivalent, and otherwise keep the same settings, the center of the resulting spectrum jumps to a much much larger value (by about 10-fold). Now, I don't know how much sense there is to use full tensors in garlic (is the anisotropic information considered in any way?) which supposedly assumes isotropic fast motion, but this matter aside, why is there a gigantic change in the spectrum's center, if I do not change input values, but just the format from a scalar (or vector, which works too) to a matrix with three equal values on the diagonal?

[Stefan Stoll]

Please post a small script that demonstrates this.

[juho.roukala]

Turns out it had to do with missing tcorr definition, so basically this appears to be a technical thing/user error - sorry for wasting your time there! Anyway, here's a minimal script to show what I mean, using example data from EasySpin documentation (does not have to make any physical sense, just a technical demo):

Code: Select all

easyspin;
Exp=struct('mwFreq',9.7);
Sys=struct('Nucs','14N','A',[17 17 84]);
Sys.g = [2.005 2.003 2.007];
Sys.g
[field1,spec1] = garlic(Sys,Exp);
Sys.g = [2.005 0 0; 0 2.003 0; 0 0 2.007];
Sys.g
[field2,spec2] = garlic(Sys,Exp);
field1(1:5)
field2(1:5)

Running it like this produces the output

Code: Select all

>> >> >> >> 
ans =

    2.0050    2.0030    2.0070

>> >> >> 
ans =

    2.0050         0         0
         0    2.0030         0
         0         0    2.0070

>> >> 
ans =

  343.5521  343.5562  343.5603  343.5644  343.5685

>> 
ans =

   1.0e+03 *

    1.0307    1.0307    1.0307    1.0307    1.0307

Which means that the same three values of g result in a highly different output of the field vector, without any errors. However, if tcorr is defined (say 1e-10), the program does yield errors, indicating that "Three values in System.g needed!" which I take means "do not give 3x3 input, even if it is a diagonal input with only three values".

User errors are inevitable, unfortunately, but I still think the program should either be capable of extracting the relevant information from a diagonal 3x3 array just as it can from a vector, or (also without tcorr defined) clearly express if this form of input is not acceptable - errorless happy output is deceptive, especially if the user doesn't suspect there is something wrong.

[Stefan Stoll]

This behavior is due to two bugs: one in garlic, where the full g tensor wasn't treated correctly, and one in fastmotion *used by garlic), which erroneously issued the error you saw.

We just posted a new version, 5.1.7, where these bugs are fixed.

Thanks for reporting!