Old Meteoplug Forum - now read-only!

Weibull-Graphs show how long a certain sensor value has been received. Putting that into a graph shows distribution of values.

This is extremely useful to make a prediction of how much power a wind power generating device might produce at this location (when you make Weibull on wind speeds).

This type of graph is very specific, as it does not show flow of time on x-axis. Therefore, I had to use a slightly different flash graphing tool from amcharts, so it looks a bit different.

You find a graph examples in the wiki here:
http://wiki.meteoplug.com/Gallery#Weibu ... n_as_Graph

...and a csv export example (to import this for computations in excel, etc) here:
http://wiki.meteoplug.com/Gallery#Weibu ... ution_Data

Excellent.

I see that the sfactor is 0.25 because the bucket size of 15 minutes is 0.25 of an hour.

Is there any way to apply a factor to the measured value to allow display in alternative units, e.g. 2.24 for mph, or 3.6 for km/h?

I did fear that this will be asked
No, not at the moment. As factors and offsets don't apply to that x-axis values,
it would need an additional mechanism to make that happen.

I just added "xfactor" and "xoffset" values for that.

to get x-axis in km/h use:
xstart=0.0
xinc=0.27777 # data gets collected from data base in the original unit (here m/s, so increments are 1/3.6) to make 1km/h steps
xfactor=3.6 # factor used to stretch results when being displayed
xoffset=0.0 # can be omitted as long as being 0.0

This combination of "xfactor" and "xoffset" should also allow for setting up x-axis as in degrees Fahrenheit (instead of Celsius) when used with a temp sensor. Please note: logarithmic adaptions like needed for conversion from m/s into BFT cannot be achieved by this.

admin wrote:to get x-axis in km/h use:
xstart=0.0
xinc=0.27777 # data gets collected from data base in the original unit (here m/s, so increments are 1/3.6) to make 1km/h steps
xfactor=3.6 # factor used to stretch results when being displayed
xoffset=0.0 # can be omitted as long as being 0.0

I just tried to get a mph distribution using:
xstart=0.0
xinc=0.447 # data gets collected from data base in the original unit (here m/s, so increments are 1/2.237) to make 1mph steps
xfactor=2.237 # factor used to stretch results when being displayed

but I'm seeing a very odd looking graphs. With a timeframe of 1Y, definition weibull_line_wind3 on my skyewright meteoplug shows an x-axis from 35mph to 39mph, and the only non-zero value is 0.2h at 35 mph. The definition is basically the standard _weibull_line, adapted for wind3, a different time frame and the xfactor adjustments.

However I don't think the problem is related to the xfactor extras, since if I remove those, I just get a graph with 0.2h at 15 m/s, which is approximately the same thing. I don't think it's the timeframe either - if I change to 1M I get a graph from 26mph to 38mph with only zero values.

Am I missing something obvious?

No, you are right. I added handling of "gtrim" value to distribution charts which allows to strip empty buckets from the output. That part had an error, filtering out all buckets with value in it.

It is fixed now. Please give it a second try.

admin wrote:It is fixed now. Please give it a second try.

That's great. Thank you.

Doing a cross check on the apparent hours in January 2010 wind3 I found the total was just under 29. I checked wind0 and got a similar figure, and again for th20.

Checking th20 for February and March 2010, those totalled to just under 28 and just under 31 respectively, so that looks okay which could mean a hole in the January data - though I'm not sure where I'm missing 3 days in January?

Checking another th sensor that was so far as I recall was operating throughout 2009 I found what appears to be some inconsistency, i.e.

weibull_csv_th3_2009-01 (timeframe=20090101000000-20090201000000) totals to 30.7 (i.e. ~31) days
weibull_csv_th3_2009-02 (timeframe=20090201000000-20090301000000) totals to 27.7 (i.e. ~28) days
but
weibull_csv_th3_2009 (timeframe=20090101000000-20100101000000) totals to 36 days

Maybe you could double check that I'm not creating a false problem through some oddity in the definitions?

skyewright wrote:

admin wrote:It is fixed now. Please give it a second try.

Checking another th sensor that was so far as I recall was operating throughout 2009 I found what appears to be some inconsistency, i.e.

weibull_csv_th3_2009-01 (timeframe=20090101000000-20090201000000) totals to 30.7 (i.e. ~31) days
weibull_csv_th3_2009-02 (timeframe=20090201000000-20090301000000) totals to 27.7 (i.e. ~28) days
but
weibull_csv_th3_2009 (timeframe=20090101000000-20100101000000) totals to 36 days

I had another look at this...

A better understanding of xymode 'buckets' helped, but doesn't provide a full solution.

The above figures were with xymode=40. The number of lines in the csv for the whole of 2009 was 16 (temps from 6 to 13.5 in steps of 0.5).

I eventually deduced that a problem was that since I was using 'xstart=-6.0', 40 x 0.5 only goes to 13.5, and th3 certainly recorded temps above that.

Increasing xymode to xymode=100 gave a csv with 43 lines, and temps from 6 to 27 in steps of 0.5. The figures in the range 6 to 13.5 being identical to the 40 bucket results.

However even with that copying the csv into a spreadsheet and totalling the hours only gave an apparent total of 90.7 days in 2009.

Increasing the precision of the increment to inc=0.2 (and increasing xymode) gained a day to 91.5 days
Increasing the precision of the increment to inc=0.1 (and increasing xymode) took the total down to 90.0 days

The max temp was 27.3, and start was 0.0, so the 500 buckets should be plenty I think.

Staying with inc=0.1 and reducing time frame to timeframe=20090101000000-20090401000000 (i.e. 1st 3 months) gave 89 days, which is okay, but stretching to timeframe=20090101000000-20090301000000 only added half a day (i.e. 89.5 apparent days in 6 months).

Is it maybe that some sort of 'ceiling' is being met somewhere?

skyewright wrote: Staying with inc=0.1 and reducing time frame to timeframe=20090101000000-20090401000000 (i.e. 1st 3 months) gave 89 days, which is okay, but stretching to timeframe=20090101000000-20090301000000 only added half a day (i.e. 89.5 apparent days in 6 months).

Is it maybe that some sort of 'ceiling' is being met somewhere?

Changing resolution to res=hour1 (and removing the sfactor), a 6 month timeframe gives ~180 days, and a 12 month fime frame gives ~360 days. That's not a solution, but maybe it helps with diagnosis?

Yes, weibull charts don't have time frame on x-axis. Therefore, amstock-charts cannot be used, I have to go with amline-charts, which allow for any x-axis values. As a consequence, you don't have a time scaling option build in.