Slowing Down the Summer Sun

[bcroe]

Here's mine.. i use a "tinytracker" trackibg system. It folows the sun until the sun goes down, and then return to start position. Feels that it helps in the winter time.

Very neat! How long has it been serving you? Bruce Roe

[littleharbor]

Beautiful location. Bummer you have to look at those high power lines and towers. Pretty cool siding on the shed.

[Glamsland]

Here's mine.. i use a "tinytracker" trackibg system. It folows the sun until the sun goes down, and then return to start position. Feels that it helps in the winter time.

[sensij]

I'm sure I'll be using the tool a lot. Every time I found a 'cool thing' I got sidetracked for a while. But I doubt it will replace PVWatts spreadsheet output for quick and dirty, at least for me.

It was probably worth installing just for the easy access to a substantial panel specification database. Gotta love government resources.

Thanks again.

I'm glad you are getting something from it! Yeah, there is a learning curve to it, and I do plenty of quick and dirty work in PVWatts too, but am glad to have more horsepower for the more challenging questions / problems. I referred to it in another thread, but I took my own exploration in the direction of making sure I could independently recreate every number that SAM produces in its performance models. NREL's technical manual for the program has a few gaps I could only resolve by going back to the original sources of the models on which it is based, but having done that, I've got a lot of confidence in its output, when used in an appropriate way.

I'll be looking forward to more of the posts about your system, and the thinking you are putting into it.

[AzRoute66]

sensij -

I have been working with the SAM tool. In the process I read the TMY user manual and it really clarified things well. Reinforced my opinion to not try to insert bad days but I see now where it couldn't hurt to find them and run them as part of the 'worst case' process, especially as when you know where/when they are for your TMY station, they can be just 'zoomed' in on if you set things up right from the start..

I'll bet you chuckled since the Example case in the SAM manual is based on the same inputs I used. I used the tool in both PVWatts mode and Detailed PV mode, and ran my situation as both an Independent Parametric and a Combination Parametric. I also ran the Example from beginning to end. I can see how a moderately experienced user can get results for many questions very quickly. Not so much for my exact situation - and I suspect not so much for a lot of worst case (or best case) focus. I would bet an experienced user would still have some difficulty in reproducing my graph (worst day) but I was able to use native outputs for worst month, after a lot of wrangling, which I wanted to see [and was going to do] anyway.

I'm sure I'll be using the tool a lot. Every time I found a 'cool thing' I got sidetracked for a while. But I doubt it will replace PVWatts spreadsheet output for quick and dirty, at least for me.

It was probably worth installing just for the easy access to a substantial panel specification database. Gotta love government resources.

Thanks again.

[AzRoute66]

Butch,

I would say that they are assumptions or starting points from which an iterative process can start. Not fudge factors. Clearly my observation of '1/2 hp moter' was not used anywhere. I got the 48V battery system assumption from a sticky where Sunking gave a rule of thumb for recommended system voltages based on array size - a table which I independently believe is pretty much right on. I could have given the engineering argument for 48V from scratch but it would have been boring and off track. I absolutely stated that the 200 Ah was just a reasonable choice, from that 20A 'falls out' (C/10), it was not meant to be anything other than a starting point.

I was not ready to follow this down to the complete battery specs at this time, but I don't think it is unreasonable to say that if I am going to point some panels East I need a certain amount of output to justify that, and that 20A covers a wide territory of battery options so it made me happy. If it turns out less, I am covered; if it turns out more I have the exact place to adjust it, either way, if significantly off it would give cause to revisit the viability of the East array concept.

A 'fudge factor' generally comes in the form of 'this is the number we calculated, now we apply a 5% adjustment'. I don't think anything in there qualifies. You ended your quotefest with, "So it is just circular logic based on a fudge factor." - Where was it? And was it a forward or backward fudge factor?

Also, how did it "impact the entire analysis" (since that is what caught my eye in the first place). In my eyes, the analysis portion ended when I said that I was not going to add the array to capture winter morning sunlight for charging purposes. Everything after was clearly branded an observation of the submitted data from another viewpoint. But, don't get sidetracked by that, "Where is the fudge factor" that ruined everything? If you insist it was the 20A 'reasonable choice', then you have me, I have no further argument for that.

[ButchDeal]

I don't think I used ANY fudge factors. But entire analysis? Backwards use of 'fudge factors'? Should be plenty of examples there for you to point out specific instances of that. You may select either forward usages OR backwards usages.

Please do not claim rounding of numbers as fudge factors, you are better than that. Let me have it. I need to learn this stuff.

lets see here is a quote:

some kind of cooling (evaporative cooling, probably 1/2 hp fan motor....

So here are the hints that a fudge factor is coming. Words or phrases like "some kind of", "probably"

but we do know that optimal maximum bulk charging current is 20 Amps.

well how do we know that? what size is the battery?

All you stated is :

this is also where I decided on a 48V battery system

ok 48V but

I decided 8 six volt batteries will be a good starting point for a 48V system and 200 Ah is a reasonable starting point to look for 6V battery deals. C/10 = 200Ah/10h = 20A

So it is just circular logic based on a fudge factor.

You decided on 48V 200Ah (that you pulled out of your a$$) is a good starting point but never changed or adjusted in any way so also a final point and everything is based on it.
You also state that C/10 is optimal charging but that is just a fudge factor for some batteries.

You try to pre-justify your decisions by pre-bashing anyone that says anything against it as an old timer stuck in their ways

BTW I have a 200ah 48V system. It is bymodal and perfect for my situation but would be very small for an off grid situation where you wanted home cooling.
My batteries can take much more charging than you specified as they are VRSLA AGM.

You also assume that all the tools are similar to the free ones you have seen. There are many tools that can simulate hourly production with shadows etc. for every day, they just cost money. Download a CSV, and make sure you can run what you want.

[AzRoute66]

But the basic idea of the suggestion was to pick worst weather days strung together for a few days. This could help with the off grid sync with reality that AzRoute66 seems to need.

I may not have worded my thoughts correctly. I was trying to tell sensij that I do not need any more synthetic reality in the weather data. In fact, the fact that we have such good weather models at all is just short of amazing - and I am grateful that I get to use it. Actually, I saw some of that 'reality' in one of the hours of my Dec 21 graph and I didn't appreciate it one little bit. If there is ONLY ONE DAY that contains completely 'real averaged' data, I want it to be December 21.

I can model the apocalypse in easier and more manageable ways than inserting a bad weather day into the underlying models. You said, "This could help with the off grid sync..." - Could you explain this 'off grid sync'?

[AzRoute66]

Your entire analysis is based on backwards use of fudge factors....

I don't think I used ANY fudge factors. But entire analysis? Backwards use of 'fudge factors'? Should be plenty of examples there for you to point out specific instances of that. You may select either forward usages OR backwards usages.

Please do not claim rounding of numbers as fudge factors, you are better than that. Let me have it. I need to learn this stuff.

[J.P.M.]

it can be even worse. Our software uses the full weather for the calculation and some of the stations were off line for periods of time or data lost etc, so they interpolated the weather from near by stations.

And then you have local weather effects, usually from large bodies of water or mountains that can effect the weather. weather stations tend to avoid these situations but when you model a home that is in the effected area using TMY from a station that isn't you get poor results. we did a bunch to correct or rather to interpolate our own TMY type data for these regions using other weather stations that are obviously less accurate but more of them.
For example near me is a location that gets strange micro weather, the Harpers Ferry pass where two rivers meet and cut through the mountain range (Shenandoah and Potomac). So there is weather funneled from the west through the Potomac cut, or from the south through the Shenandoah cut and then heading East to follow the Potomac cut through the mountains.
Then you have two rivers with different temperatures meeting (Potomac colder, Shenandoah warmer). The area is usually 5 degrees colder than 2 miles away with higher humidity and a lot more fog. The area also gets more rain and snow fall but most importantly (for solar discussion) has considerably more cloud coverage. So Harpers Ferry is a low town surrounded by mountains so it has shorter day light from mountain shadows and considerably more cloud coverage...

Understood.

Bottom line for weather databases may be a mixed bag. While there is no way to predict future weather, and that's a fact, climate expectations seem more benign and predictable. For example, there's a fairly high probability that any day in summer will be warmer than any day in winter. That's climate. But the actual weather on the winter solstice of any year has a small but non zero probability of being warmer than the weather on the preceding or following summer solstice. That's weather.

So, in spite of the shortcomings which I rail about, things like TMY data are useful for long term expectations of system performance, provide the limitations are kept in mind. Those limitations are one set of reasons why output from models such as PVWatts are mostly useless for short term predictions of system performance or expectations of system performance, and, as I'm sure you know, make statements like "PVWatts predicted my system would do better yesterday/last week/last month than it actually did - what's wrong with my system ?", seem silly.

On the other hand, given the variability of the weather, and to a lesser degree the variability in climate, some errors in the TMY data bases from extrapolation or estimation may be tolerable, even if annoying. In any case, they are what they are, and better to be aware that such deficiencies exist and try to account for them than to ignore them. Given the year/year variability in weather of say, 5 to 10% or so, if a judicious choice of station and with some tolerance in interpretation of the results can be used, an error in the output of a few % due to less than pure TMY data may be tolerable.

[sensij]

A look at a TMY file will usually be a smoking gun when looked at with an eye toward the station class (with the 26 Class I being the best and all the other 1,400+ stations being Class II or III), the uncertainty flags, and a look at some of the data fields that are often clearly and blatantly interpolated data.

This is another one of the reasons I am glad I installed SAM. It includes a library of TMY files in human readable format, and there is a lot to be learned by looking at the information within them. (There are other places to download the files, and TMY isn't the only game in town, but the convenience of bundling with the SAM install is nice). While PVWatts treats the TMY files as something akin to a black box, leading to misuse and misunderstanding by some users, I think SAM is a little bit more transparent about how the TMY data are used.

Seems like a good place to link the TMY user manual:

http://www.nrel.gov/docs/fy08osti/43156.pdf

A small correction to what was written in posts above... the TMY is constructed from typical *months*, not typical *days*. 12 degrees of freedom, not 365, since the identification of "typical" requires looking at variance, and monthly timeframes with daily variance show that more clearly than daily timeframes with hourly variance (I think).

AzRoute66 , there is still lots to talk about. I agree there are logical problems with some of the way "autonomy" gets thrown around, but also recognize that systems designed on that concept are generally robust enough to successfully handle most of what they will encounter. The "large enough" question is fair too, since some of the optimization we are discussing just doesn't make sense for smaller systems. You'll see a lot of threads for RV's and other small vehicle conversions, those are generally satisfied by 600 W, flatmounted on a roof, and it isn't too expensive to just throw capacity at it instead of trying to optimize. Bigger systems requiring 2kW or so tend to be the next class worth discussing, but even at that level, the costs get significant enough that there aren't too many people here who follow through with actually building and living it, most get turned off when they grasp what is really involved. The system built by hammick might be a good example, as described in this thread, and others.

The system you are proposing is bigger still, and moves into a class of equipment that is even more expensive, where you'll probably want to be looking at 600 V strings and maybe a battery bigger than 48 V. I'm not sure there are any good examples of systems worked out at that scale here in the forum. OffGridHawaiian built a large system and shared some details about it, but insisted on using Aquion batteries so some of the experience isn't very transferable.

I think you'll see lots of conversation about PV tilt and orientation in the grid-tie threads, less in the off-grid threads because there tend to be bigger problems to address. I think the conversations are worth having, but the science is well understood and the modeling tools are readily accessible, so the more interesting conversations at this point (to me) are less about the theoretical observations and more about how to apply them in the real conditions that people encounter. The costs and benefits of extending the charging day are (I think) topics that have not been well explored here, so I hope you continue to climb the learning curve and share what you find, even if some of what you write won't age well.

[ButchDeal]

Thank you for the reply. I believe I understand what you write here and the purpose of your post to AzRoute66.

Most stations do not have pyranometers for measuring GHI, and fewer yet have or pyrheliometers to measure DNI.

A look at a TMY file will usually be a smoking gun when looked at with an eye toward the station class (with the 26 Class I being the best and all the other 1,400+ stations being Class II or III), the uncertainty flags, and a look at some of the data fields that are often clearly and blatantly interpolated data.

it can be even worse. Our software uses the full weather for the calculation and some of the stations were off line for periods of time or data lost etc, so they interpolated the weather from near by stations.

And then you have local weather effects, usually from large bodies of water or mountains that can effect the weather. weather stations tend to avoid these situations but when you model a home that is in the effected area using TMY from a station that isn't you get poor results. we did a bunch to correct or rather to interpolate our own TMY type data for these regions using other weather stations that are obviously less accurate but more of them.
For example near me is a location that gets strange micro weather, the Harpers Ferry pass where two rivers meet and cut through the mountain range (Shenandoah and Potomac). So there is weather funneled from the west through the Potomac cut, or from the south through the Shenandoah cut and then heading East to follow the Potomac cut through the mountains.
Then you have two rivers with different temperatures meeting (Potomac colder, Shenandoah warmer). The area is usually 5 degrees colder than 2 miles away with higher humidity and a lot more fog. The area also gets more rain and snow fall but most importantly (for solar discussion) has considerably more cloud coverage. So Harpers Ferry is a low town surrounded by mountains so it has shorter day light from mountain shadows and considerably more cloud coverage...

[J.P.M.]

absolutely right. I was just pointing out that TMY is not a model, it is a year built of of 365 days from past years where they picked the most typical day from one of the years for each day of the TMY. So in some TMY data points the days are real data and in others it is a mix of real data and simulated other data like insolation.

Now some stations do not have pynanometers or didn't for very long so irradiance would be simulated from other models. But the basic idea of the suggestion was to pick worst weather days strung together for a few days. This could help with the off grid sync with reality that AzRoute66 seems to need.

Thank you for the reply. I believe I understand what you write here and the purpose of your post to AzRoute66.

Most stations do not have pyranometers for measuring GHI, and fewer yet have or pyrheliometers to measure DNI.

A look at a TMY file will usually be a smoking gun when looked at with an eye toward the station class (with the 26 Class I being the best and all the other 1,400+ stations being Class II or III), the uncertainty flags, and a look at some of the data fields that are often clearly and blatantly interpolated data.

[ButchDeal]

Butch: TMY is a useful tool, and easy to use, either as part of a model or by itself for other/related purposes.

But, to say that it's is a record of things that actually happened or were measured needs some clarification.

a good part of the data in the TMY data bases is actually modeled or synthetic for most stations, although you and I and others need to root in and around the TMY data and what's written about it to dig that fact out.

Depending on the station, for example, sometimes all of the solar irradiance data is modeled. The TMY handbook mentions this, but kind of downplays the extent. To get a feel of how much of the data is modeled or synthetic, one needs to dig around in the TMY user manual. Much of the irradiance data for Class II or Class III sites, which are most of the 1,400 TMY 3 sites, are based on good eyeball ground observations of cloud cover data, or extrapolations from other stations, or other methods such as satellite modeled irradiance data. Most stations/TMY sites do not have pynanometers or other irradiance measuring equipment. This is in addition to extrapolations for missing data.

I understand what you're writing about with respect to using worst day data, and short of having actual, on site recorded data, the TMY data is probably better than all or most other stuff. But to call most of the TMY data "actual" may not be an entirely accurate representation of the data.

absolutely right. I was just pointing out that TMY is not a model, it is a year built of of 365 days from past years where they picked the most typical day from one of the years for each day of the TMY. So in some TMY data points the days are real data and in others it is a mix of real data and simulated other data like insolation.

Now some stations do not have pynanometers or didn't for very long so irradiance would be simulated from other models. But the basic idea of the suggestion was to pick worst weather days strung together for a few days. This could help with the off grid sync with reality that AzRoute66 seems to need.

[J.P.M.]

Can you know better than PVWatts? some of us do. It is just a model, no better than the setup and data put into it. SAM is a better model. Aurora has an even better model.

BTW, PVWatts uses TMY so as Sensij mentioned, picking the worst days and modeling them is important because those worst days ACTUALLY HAPPENED.
Thats how TMY is made, they pick typical days out of the past set of years (number of years varies from location to location) and stick them together to make a Typical year. so Monday could be from 2015, Tuesday from 2000, Wednesday from 1999, Thursday from 2010 etc. Often the bad days (atypical) are grouped together each year.

Butch: TMY is a useful tool, and easy to use, either as part of a model or by itself for other/related purposes.

But, to say that it's is a record of things that actually happened or were measured needs some clarification.

a good part of the data in the TMY data bases is actually modeled or synthetic for most stations, although you and I and others need to root in and around the TMY data and what's written about it to dig that fact out.

Depending on the station, for example, sometimes all of the solar irradiance data is modeled. The TMY handbook mentions this, but kind of downplays the extent. To get a feel of how much of the data is modeled or synthetic, one needs to dig around in the TMY user manual. Much of the irradiance data for Class II or Class III sites, which are most of the 1,400 TMY 3 sites, are based on good eyeball ground observations of cloud cover data, or extrapolations from other stations, or other methods such as satellite modeled irradiance data. Most stations/TMY sites do not have pynanometers or other irradiance measuring equipment. This is in addition to extrapolations for missing data.

I understand what you're writing about with respect to using worst day data, and short of having actual, on site recorded data, the TMY data is probably better than all or most other stuff. But to call most of the TMY data "actual" may not be an entirely accurate representation of the data.