New Group on Linked In

I started a group on linked in called “Solar Design”

Here is the link:

http://www.linkedin.com/groups/Solar-Design-5107996?trk=myg_ugrp_ovr

I did not see a place limited to the technical discussion of the PV industry from the viewpoint of design, engineering and project management. The PV groups I have been in tend to be very general with information all over the place, and thus not very helpful, in my opinion. I want a place where people can have real meaningful conversations and share very practical knowledge that may not be very easy to come by- and in a centralized location. Right now it just coincides with this blog, but hopefully should take on a life of its own as it grows.

Feel free to join the conversation.

-Marc

Advertisements

Estimate Soiling

So, we all know PVsyst has many variables, many of which are not very straight forward. It however still remains the best tool in estimating system production. The detailed losses section of grid-tie systems has many inputs, a few of which seem to be at the user’s discretion with little direction from the software, or online for that matter. Chief among these in my mind is the soiling loss tab. It can be set to the 3% yearly soiling loss factor, whatever the user decides to input as a yearly loss factor, or the monthly soiling values can be set based on the user inputs. So how do you go about estimating these losses? I’m glad you asked 😉
One could suppose 3% as a standard, as this is in the software after all. But does that really account for all of the soil types, location features, and weather patterns. I suppose definitely not. Perhaps we could assign different numbers for different regions- but then how do you assign those numbers, and how do they maintain any accuracy at unique sites? Perhaps we can get more accurate with monthly values instead of yearly, but then we have the same problem with more information for the user to provide.
My solution is to capture weather data and site data and perform an algorithm to convert that data into meaningful inputs. This would be a big undertaking to do for every site that needs a PVsyst report generated however, so this would need to be automated. Well, I went ahead and did just that. Select a city, select some information about the site, and presto- monthly soiling loss values, based on real world information.
Another use for soiling data is to know when to clean the system for maximum system production increases with minimum cleaning expenditures. Without knowing when the system needs to be cleaned, any cleaning schedule planning is bound to leave money on the table. An average frequency approach will leave some sites cleaned too often and others not enough, too little washing on all sites and production is impacted, too much and you are literally washing profits into the gutter. You also want the cleaning to be performed at the right time of year so the junk gets cleaned out just in time to let the light in, and when Mother Nature’s cleaning system is not doing you any favors. Based on accurate site information, the soiling estimating tool that I have developed can tell you exactly what time of year (for a typical year) is optimal for module cleaning. It can also tell you what your impact to production is without a cleaning, which can be a valuable deciding factor when determining frequency of cleaning.

Text Cleanup Tool

I found one of the most useful AutoCAD tools recently. Although I don’t share every free tool I find, I felt this one was especially useful enough and well executed that it needed to be shared. It is called Strip Mtext, from cadabyss, written by Steve Doman and Joe Burke. The one I have is version 5.0, and uses the command SMT once the .lsp file is loaded into AutoCAD. The command brings up a well-organized menu that will strip out any formatting done to the selected text. This may sound insignificant, but I have been dealing with companies lately where they send multiple files with many instances of formatted text. This may be because the files have been worked on by multiple individuals or companies already, I am not sure, but it is very random and time consuming to open each text instance and edit out the formatting. This tool has recently saved me a ton of time on an otherwise very tedious task. Google it and get it for yourself.

Efficient String Layout

When it comes to designing a string layout diagram, there seems to be about a million ways to do it. Everyone seems to have a unique take on this redundant and time consuming task. Variables shown in string diagrams often include naming conventions, symbols, and grouping patterns for legibility. Not only are these variables always depicted a little bit differently, but the methods in which individuals and organizations go about creating these variables seem to vary too. Most shops do everything manually in the CAD software, and some places have had developers come up with add-on tools or programs to try and automate this process. The tools that I have seen are far too rigid and often just don’t work. For example, they need to be exploded and manually adjusted, or deleted and re-created if anything changes. These issues may create even more work for the user.

So I set about making an automated tool using multiple files that allows for the most efficient mix of automated and manual methods to create these drawings. To use this tool symbols are copied, lines are drawn without any additional programming aid, and naming tags are automated in a way that allows for very fast naming both initially and down the road if and when changes occur. Of course as we all know, changes almost always do occur. This tool is not only by far the fastest that I have seen, but also really helps take the pain out of a process that may otherwise contain thousands of repetitive movements. For comparison, the manual method done quickly may require the following inputs for each instance of tag editing/creation: double-click to edit, enter and delete multiple characters of text, double click to exit. In contrast, once the automated tool is in place this becomes: enter, single click, enter. This may seem minor, but if you consider that a system may have hundreds of strings, this could save thousands of clicks and keystrokes. Then potentially double that whenever a layout needs to be changed. So this is clearly not only a time saver, but a wrist and finger saver as well.

Sizing Underground Conductors

After having visited the tedious bowels of the NEC otherwise known as Annex B on a few occasions now, I have decided to make a tool that allows for quick reference of this section.  After having this consideration brought up on a few occasions, and having to re-examine and re-read this text ro prove my conduit bores were not too deep, now anyone can click a few buttons and come up with exact depths and current values.  Although this section is to be calculated under engineering supervision per NEC, due to the inherent “complexity” of the math and variables, the tool makes it very easy.  No more charts, no referencing and flipping between multiple pages, no calculations, no guessing RHO values: select a few drop downs, enter a current value and your done.  Not that any inspector has ever questioned adherence to this annex on a project that I have ever worked on- but at least we can sleep easier at night now knowing that our conductors can adeqautely dissipate heat when they are 10 ft deep. 

In-Depth Transformer Sizing

After working on a series of projects where transformers seemed to be getting oversized as a cautionary step, I started doing some research on approaches to transformer sizing. I had worked with a cooper power rep prior to these projects, and we were overloading the transformers to a certain extent. So I set out to find the proper balance for value engineering over the life of the system, balancing life-expectancy, efficiency and of course hardware costs. This is, of course, is no small task. After some digging, I found some good information, including a great article on sizing and selecting transformers in a real world application (here: http://ecmweb.com/content/guidelines-transformer-application-designs).

I have summarized some of the carrots picked up and shown in this list:

· “STC” for transformers is 30C average over 24-hr, and 40C maximum.

· Temp. Adjustment > 30C = -0.4% kVA / C (or select a lower temp. rise)

· Insulation classes for dry-type transformers: 105/150(B)/180(F)/220(H)

· Temp. Rise (with allowable insulation class): 80(H,F,B)/115(H,F)/150(H)

· Temp. Rise is determined by full-load Rise/ambient(~40C), with 30C hot spot.

· Insulation classes for liquid transformers: 55(old)/65(new)

· Generally, the greater the continuous-operating load, the more cost effective lower rise transformers become. 80(>75%)/115(>65%)/150(>50%)

· Overloading should involve discussion with the manufacturer, in accordance with ANSI C57.96-1989, as degradation of the insulation can affect the life-expectancy.

· Voltage > 35kV requires 3-hr rated vault

· Sizes > 112.5kVA located indoors require fire rated rooms

Transformers should be sized working with the manufacturer with a proper insulation based on system size, location, ambient temperature and loading ratio. Determining the continuous load ratio becomes more complex when using a renewable energy source supplied from an inverter, and should be balanced with maximum load ratios during peak production. Sizing a transformer without the up-front diligence can easily lead to leaving money on the table.

So, what loading ratio should a solar power system transformer use? It depends. Should the kVA rating be exceeded? Yes. Should the kVA rating be exceeded at continuous-operating load? No. What ratio should be used? Size based on site conditions while working with the manufacturer.

East West shade

Shade from point source objects to the south of fixed-tilt arrays in the northern hemisphere are always of concern when estimating production.  Objects to the East and West are obviously going to be of conern as well.  However, I have run into a few situations lately where point source and horizon shade sources are being discounted when they shade mainly north of the array, and only “somewhat” to the East or West.  While we can run these scenarios in PVsyst or with boots on the ground with a Suneye, with much effort, I think it is critical to have a tool to easily identify and estimate these impacts from the office.  I have seen a tool like this before, so awhile back I developed my own version.  Select a latitude, click OK, and then you have yourself a script file to automatically generate the tool within AutocAD.  Of course, we still need PV syst to tell us exactly what the production impacts will be if we choose to have array within an area that will recieve more than negligible amounts of shade. I will share the assumptions I made for setting the parameters of this tool in a future post.