I think I may have erred in the data packing formula for the nth_row of the 2-D extract. It may be
{(K=1,Npp) [(J=1,3) <t=(nth_row,1024,stepJ*K) (t,detOpJ,ppK)>]} … where the inner loops are executed first. i.e. 1st the <…> loop, then the [ …] loop, and finally the {…} loop.
[...]
Hi Paul:
After composing mu last email, I did start to think about the time dependent “detect_operators” and how allowing for those would negate the approach I suggested, in addition to the circumstances you mention below.
I do like your demonstration of the effects of turning on/off certain components of the dipolar couplings.
However, that is not what this email is about. I think something has gone sideways with the mapping the data into the matlab 3-D name.data array (assuming “only” time + two virtual dimensions are present) data structure,at least when the detect_operators are taking part as one of the virtual dimensions.
Firstly the name##.fid files look correct and faithfully follow the implied order of the virtual dimensions.
Lets assume the there are:
np 1024 %time pionts as 0th virtual dimension
detect_operator {detOp1, detOp2, detOp3}:1 %3 detect operators as 1st virtual dimension
pulse_param {pp1, pp2, pp3, pp4, … ppNpp}:2 % Npp pulse parameters as 2nd virtual dimension
In the matlab structure, the name.data array correctly reports as a 1024x3xNpp array
Also matlab reports that the squeeze(name.data(:,1,:)) as the expected 1024xNpp 2-D array
However, the data in that 2-D is not arranged in the time x Npp “plane”. One row of the matrix seems to cycle through the 1024 data points defined by
{(K=1,Npp) [(J=1,3) <t=(1,1024,stepJ*K) (t,detOpJ,ppK)>]} … where the inner loops are executed first.
At least, this is my first impression.
Regards
Syd
I think I may have erred in the data packing formula for the nth_row of the 2-D extract. It may be
{(K=1,Npp) [(J=1,3) <t=(nth_row,1024,stepJ*K) (t,detOpJ,ppK)>]} … where the inner loops are executed first. i.e. 1st the <…> loop, then the [ …] loop, and finally the {…} loop.
[...]
Hi Paul:
After composing mu last email, I did start to think about the time dependent “detect_operators” and how allowing for those would negate the approach I suggested, in addition to the circumstances you mention below.
I do like your demonstration of the effects of turning on/off certain components of the dipolar couplings.
However, that is not what this email is about. I think something has gone sideways with the mapping the data into the matlab 3-D name.data array (assuming “only” time + two virtual dimensions are present) data structure,at least when the detect_operators are taking part as one of the virtual dimensions.
Firstly the name##.fid files look correct and faithfully follow the implied order of the virtual dimensions.
Lets assume the there are:
np 1024 %time pionts as 0th virtual dimension
detect_operator {detOp1, detOp2, detOp3}:1 %3 detect operators as 1st virtual dimension
pulse_param {pp1, pp2, pp3, pp4, … ppNpp}:2 % Npp pulse parameters as 2nd virtual dimension
In the matlab structure, the name.data array correctly reports as a 1024x3xNpp array
Also matlab reports that the squeeze(name.data(:,1,:)) as the expected 1024xNpp 2-D array
However, the data in that 2-D is not arranged in the time x Npp “plane”. One row of the matrix seems to cycle through the 1024 data points defined by
{(K=1,Npp) [(J=1,3) <t=(1,1024,stepJ*K) (t,detOpJ,ppK)>]} … where the inner loops are executed first.
At least, this is my first impression.
Regards
Syd