Renewables: "talking 'bout my generation"

zeupater

jimmyboy420 wrote: »

Nice. I need to try and target my spreadsheet to do this, it's complicated though - you don't really know what you want at the beginning/end, unless you assume that June and December are flat, and then you can interpolate between them...

Hi

:think: .... It's not really rocket science so it not a case of needing to be the 'sharpest tool in the shed' to come up with a workable solution ... how about taking each month end PVGIS figure as being the average of the two months it falls between then apportion the difference to the actual month average on a daily basis ... of course, there's arguments to be had around the summer and winter solstice day lengths not falling between those at the start and end of the month and a general time shift between them and mid-month days ... but, considering that the spread of day lengths in June & Dec are around 20seconds (where we are) against this months ~2hours (where we are), just how accurate would the interpolation need to be? .... after all, what's the chance of not getting ~20seconds more or less of cloud at any time in June or December ...;)

The thought process above took less than it takes to write '..' - I'd also hazard a guess that it's the basis of the system which Mart is using .....

HTH
Z

Martyn1981

jimmyboy420 wrote: »

Nice. I need to try and target my spreadsheet to do this, it's complicated though - you don't really know what you want at the beginning/end, unless you assume that June and December are flat, and then you can interpolate between them...

Hiya Jimmy, working (of course) on the basis that this is only silly fun, and not in any way accurate, it's not too hard to get a reasonable pro-forma/template to write over each year.

I take the month target, divide by the number of days, then 'fudge' em a bit! So if September target is 300, the average is 10, which fudges into 11's at the start, 9's at the end, and 10's in the middle.

It quickly tests itself, as you see how the months meet, are the 'joins' similar.

Chatted about this ages ago with Eric, he had a good idea (hope I've got this about right) take the average of two months, which should suggest/hint at the figure in the middle where they meet. If you did this for all 12 joins, that's a good start to again fudge the daily figures.

Whilst nothing more than fun, it does allow me to see how a month is going, always on the basis that the rest of the month is average, and that my pre-inserted averages are reasonable. But of course weather is never average on a daily basis, so nothing to prevent 1/9 being the worst day of the month and 30/9 being the best.

Edit: Looks like Z came up with all the tricks, super quick. A+ in the post. M.

Mart.

jimmyboy420

:-/ OK, I get it. Thanks for the responses!

Martyn1981

zeupater wrote: »

Hi

after all, what's the chance of not getting ~20seconds more or less of cloud at any time in June or December ...;)

HTH
Z

Yep, very flat months on my made up spreadsheet. For the ESE system June's total works out at 3 13's and 27 14's, so I just stuck a 13 on the 1st, 29th & 30th. This matches the end of May and the start of July both with 13's.

But again, only a bit of fun, but having done it once, it doesn't need to be done again ...... even if PVGIS revise their figures, I doubt I'll bother as they are only average targets anyway.

Mart.

zeupater

[QUOTE=jimmyboy420;66518092[/QUOTE]
Hi

Really ??? .....

Two numbers, say 200 & 300 ... and average them ... so 250 ... when apportioning numbers between 200 & 250 to the intervals in-between, surely the number can't be higher than 250, conversely a number between 250 & 300 can't be less than 250 ....

HTH
Z


##Edit ... Seeing the referenced post changed significantly .... I think that the penny dropped a fraction after 12:27 ... ... but then again, doubt resurfaced again at 12:37 (below) ... "...though looking into it more, I think you can still get odd results like 30th April having higher expected generation than 1st May! I'll play around a bit more. " ... no, as explained above - it can't

jimmyboy420

...though looking into it more, I think you can still get odd results like 30th April having higher expected generation than 1st May! I'll play around a bit more.

jimmyboy420

zeupater wrote: »

##Edit ... Seeing the referenced post changed significantly .... I think that the penny dropped a fraction after 12:27 ... ... but then again, doubt resurfaced again at 12:37 (below) ... "...though looking into it more, I think you can still get odd results like 30th April having higher expected generation than 1st May! I'll play around a bit more. " ... no, as explained above - it can't

Thanks,
You're right of course - it took me a little while to understand your method. Now that I've understand it, I encounted a related "problem". The total for each month is now impacted by the PVGIS estimate for the preceding month, and the following month (because they're used in calculating the targets for the end of month dates). This means the total for month X does not add up to the PVGIS target for month X.

Now, with the figures we've derived so far, we could scale each months figures so that they add up to the PVGIS target for the month.

But this does indeed lead back to the problem of having, e.g., 30th April with a higher target than 1st May.

It's entirely possible that I'm either missing something simple, or, trying to make it an overly accurate model and over-complicating it.

EricMears

Martyn1981 wrote: »

Chatted about this ages ago with Eric, he had a good idea (hope I've got this about right)

Course you have - I'm full of them

You could actually take the process a bit further and estimate the expected figure for (say) 15th Sept as being the average of August, September and October then carry on and estimate expected fig for 7th or 8th as being average of figures previously calculated for 1st and 15th. or even go on to get a figure for 4th from ave of 1st & 7th.

But where we might disagree is on how worthwhile it is ! Afraid I take the view that weather is so unpredictable that any particular day stands a good chance of being really bright & sunny or completely overcast and that sort of error would change a day's output by rather more than moving the date a month forward or back. I wouldn't therefore make any attempt to forecast what my September output is likely to be on the basis of what it was for half a month plus what it might be for the other half ! I'll wait until dusk on 30th before doing any maths.

As I'm sure I've said before, comparing actual results with the PVGIS expectations for that period can be quite useful but you need a set of them to determine a trend before you can condemn your system as needing some sort of maintenance.

zeupater

jimmyboy420 wrote: »

Thanks,
You're right of course - it took me a little while to understand your method. Now that I've understand it, I encounted a related "problem". The total for each month is now impacted by the PVGIS estimate for the preceding month, and the following month (because they're used in calculating the targets for the end of month dates). This means the total for month X does not add up to the PVGIS target for month X.

Now, with the figures we've derived so far, we could scale each months figures so that they add up to the PVGIS target for the month.

But this does indeed lead back to the problem of having, e.g., 30th April with a higher target than 1st May.

It's entirely possible that I'm either missing something simple, or, trying to make it an overly accurate model and over-complicating it.

Hi

It's all in the formula ...

You have a total for the month already from PVGIS ... this is fixed and will be the value to be apportioned over the available days .... the issue is the apportionment

You've interpolated what the generation would be at change of each month from the averages .... so you have a fixed value to apportion (the minimum daily) and the variable (max-min) to increment by day ....

The important point to remember is that you are only apportioning the monthly PVGIS total over the month, therefore the logic sanity test is that the total for the period when summed must balance back to PVGIS or the formulae employed are in error ...

HTH
Z

lstar337

Out of curiosity, does anybody here know how to get hold of recorded daily temperatures for a given area?

I have a simple spreadsheet that I use to log information on gas/electric used and generated, and I want to add a weekly average temperature to see how it affected the usage. I need to go back to April when I started logging for this year.

Thanks.