Possible 95% Threshold Discrepancy

Two data thresholds are used for the M4 tower sonic data processing (92% and 95%):

tower.sonicpassrate = 0.920000000000000 tower.sonicrotaterate = 0.950000000000000

I would have expected any values that use the sonic (u, v, w) coordinate system (i.e. rotated coordinate system) to have at least 95% of the data record. This does not seem to be the case. Instead it seems that the 92% threshold is used rather than the 95% threshold for the rotated data.

I have included a small script that will identify the issue. I have also posted the figure from the script output. In order to run the script, load the file into MatLab from the server located here:

wind.nrel.gov/MetData/135mData/M … 13_May.mat

And then run the program (or just look at the attachment).

Notice in the image that the nPoints percentage is at 92% before any plot points are visible. When nPoints are less than 92%, all MO length values are NaN. The NaN’s are of course expected except that they should occur below 95%, NOT below 92%. Am I thinking about these two thresholds correctly? I have probably just missed something, but any help would be appreciated.

Everett

%load('2013_May.mat') This is the current M4, 10-minute data file on the server

x = all_data.MO_Length_Sonic_15m.npoints/12000; % percentage of data points available (row vector)
y = all_data.MO_Length_Sonic_15m.val; %Values of Monin Obukhov Lengths (row vector)

temp = [x ; y]'; %create matrix with 2 columns
test = sortrows(temp); %Sort rows according to percentage of data points available (i.e. the x variable above)

figure
plot(test( :,1), test( :,2)/ min(test(: ,2))) %Normalized by minimum MO Length
xlabel('nPoints (Normalized by 12000) (i.e. %)');
ylabel('Monin Obukhov Length (Normalized by Min Value)');
title('Sonic 15m MO Length Vs. nPoints');

Sonic 15m MO Length Vs nPoints.png

That’s another bug, apparently. It seems that the wrong threshold was being used in the code, so that intervals with 92% or more data were being rotated. I will try to post updated data in the next few weeks.

I’ve just started the new code running (version 1.27) which should correct this. I’ll post a link to that update in a minute.

I really like the comparison of the range of MO-length with the data availability. I had a feeling that it was important but I’d not managed to show it quite as well as the plot that is shown in the previous message. Thanks!