Gridlab solar object with properties that can be pulled from a hardware spec sheet.

[dpinney]

Currently the variables that define a PV generator in Gridlab are things like area and efficiency. But a panel spec sheet specifies max powerpoint current, open circuit voltage, etc.

TODO:

1. Doug Danley @drdanley to provide list of inputs to a solar model. Done.
2. PNNL to implement in existing or new solar object class.
3. Doug @drdanley to evaluate outputs of new model.

[dpinney]

Existing Gridlab-D solar object documentation here: http://gridlabd.me.uvic.ca/wiki/index.php/Solar

[trevorhardy]

I've done some digging into this problem and here's what I've found: I think that fitting common data sheet parameters for solar cells can pretty easily be fit into our existing model. The trick is knowing which values to put where.

As with many Gridlab-D models, not every parameter needs to be defined to get the simulation to run. There are cases where different parameters are used based on the choice of other parameters. For example, when using our solar panel models the users choice in specifying "SOLAR_POWER_MODEL" will determine if "a_coeff" needs to be defined or not. In most (hopefully all) cases, if an important parameter has not been given a value by the user and Gridlab-D can make a reasonable assumption, it will. These default values may or may not match the case the user intends to model but by using default values, the simulation can march on. For those that feel so inclined, these values can be found in the code, usually in the "create" or "init" functions for the module in question.

All this being said, here are the values that I think a typical user would need to define to best capture the performance of a given solar panel using our existing model. This is not all the necessary parameters you would include in the .glm to simulate a PV installation, just those that have to do with the panels themselves.

• panel_type - Material used in constructing the panel; seems to be always found on the data sheet. (SINGLE_CYRSTAL_SILICON, MULTI_CRYSTAL_SILICON,...)
• NOCT ['F] - Nominal operating cell temperature. Found explicitly on all the data sheets I looked at.
• Rated_Insolution [W/sq.ft.] - This is the irradiance value at which the rated power occurs, almost always 1000 W/m^2 (92.9 W/sq.ft.). Note this is a power/area and really should be named "Rated_Irradiance", insolation is energy/area. I feel embarrassed for us. Its also important to note there is no direct specification of the installations rated power but rather this parameter (along with two others explained below) are used to calculate the rated power as:

Prated = Rated_Insolation * efficiency * area

• Pmax_temp_coefficient [%/'C] - This is often give directly on the solar panel data sheets in these units but I've occasionally seen it given in absolute units such as mW/'C. In these cases the user will have to do the calculation to convert the units.
• Voc_temp_coefficient [%/'C] - Same as above.
• V_max [V] - The name is ambiguous but this is the maximum power point voltage at rated conditions (usually 25'C, 1000 W/m^2) for the entire installation. This is the voltage that feeds the inverter. Typically available directly from the data sheet as a per-panel value but would need to be scaled according to the installation size and configuration.
• Voc_max [V] - Another ambiguous parameter name; this is the per-panel open-circuit voltage at 25'C.
• Efficiency [co-efficient] - Value from 0 to 1 and assumed to be constant across all temperatures and irradiance values.
• Area [sq. ft.] - Total installed area. If more than one panel is installed (almost always the case), the user will have to multiply the number panels by the per-panel area to get this value.
• Derating - Another ambiguous parameter name. This is the manufacturing process derating representing the percentage of panels that do not quite meet their stated power ratings with "1" indicating all meeting the stated ratings. This factor will be used to derate the power output all the panels. In looking at data sheets for panels being sold today, many are advertising no underperforming panels from the factory so for new panels, this can probably be set to "1". This parameter could also be used to represent degradation due to aging (found on some of the data sheets I looked at).

The data sheets I looked at had many more parameters than we support in our existing model and thus, it would be reasonable to expect the output of Gridlabd-D to show some variance from actual panel performance. If there are specific data sheet or model parameters that are important to be included in the simulation calculations, let us know and we'll see what we can do.

[dpinney]

Thanks Trevor. The solar engineer at NRECA has some additional questions. He's out for a month, so I need to set up a meeting with him for December 9ish to figure out what I need to do next.

[dpinney]

@drdanley spec memo on what values a user should know about their system is here:

https://www.dropbox.com/s/ku102e54w4t0toa/Danley%20memo%20on%20use%20of%20datasheet%20values.docx?dl=0

Note that there are 8 total variables a user should enter to specify a grid-tied system for the OMF (5 for the array, 3 for the inverter).

[dpinney]

December 9th call notes and new todo:

TODO

• Create a solar test ,glm. It should have an inverter, panel and recorders. The intent is to measure the power output of the panel and inverter. Done, in /omf/omf/scratch/solarSamComparison/.
• Find a function F(rated_power) -> (area[sf], efficiency). This allows us to map a user-entered rated_power to inputs that a GLD solar object can use. F = lambda rated_power:(75*rated_power, 0.155)
• Compare output from test .glm objects to outputs from PvWatts using the same inputs. The hope is that the AC output from the GLD inverter matches the AC output curve from PVWatts. This todo will likely require modifying the GLD solar object parameters that aren't the user-entered ones to achieve a best match. It's good. Well within 10%.

NOTES

• As noted above, we agreed on the call that there are 8 "blessed" inputs that a user should put into the OMF to specify their system. See spec memo above for details.
• Scale: OMF users need to model PV systems between 1 kW and 1 MW.

NICE TO HAVES AFTER TODOS ARE DONE

• Testing clipping - if the panel DC output is greater than the inverter rating, does the inverter cut off the excess? That works. Can we measure how much energy is rejected?
• Can we specify inverter kVA/PF on a schedule changing hourly? Confirmed working.

STRETCH GOALS FOR MAYBE SOME DAY

• Add a rated_power parameter to GLD solar object so users don't have to use the efficiency/area interface if they don't have that info.
• Add a tare load (parasitic load) to the inverter model for losses when it has no DC input.

ULTRA-STRETCH GOAL

• Investigate how to set inverter parameters for low voltage ridethrough, volt-var control, ramping limits, etc. (see drdanley spec).

[trevorhardy]

To streamline the specification of the solar panels for OMF users and not have to monkey with the GLD code, here are the "behind-the-scenes" values that OMF should define for a given solar installation.

• efficiency = 0.15
• derating_factor = 1
• soiling_factor = 1
• Rated_insolation = 92.902 (this is in W/ft^2 and is equal to 1000 W/m^2)
• NOCT = 118.4 (this is in 'F and is equal to 45 'C)

The OMF user can then explicitly define the power temperature coefficient (Pmax_temp_coeff) and the desired rated power in kW. I've done the algebra with the existing GLD model and we can then translate this given power into an array size using a factor of 66.6667 ft^2/kW. I'm very confident this will work just fine but will still run the simulations to double-check.

Regarding the physical set-up of the array here's what we have that is actually implemented in GLD for the orientation_type.

• DEFAULT - comments in the code state this is "ideal tracking" which I take to mean magically always pointed so the panel is normal to the sun. Looking at the code this seems to be the case. Let's call this two-axis where we never have to worry about shading.
• FIXED - Fixed orientation where both the elevation and azimuth can be defined. The azimuth is defined with 0 indicating pointing towards the equator.

And that's it. For residential installations this is fine as we have the typical fixed installation covered. For commercial-scale installations, having only two-axis tracking is definitely a problem but this is what we have to work with right now.

I'm next going to build up a simple GLD model with an single solar panel installation (likely fixed-axis) and an inverter to verify the power-to-area conversion factor plays out. Is there anything special I need to know about running comparison test cases to PVWatts? I'll probably just pick a few days out of the TMY2 data to test and record a bunch of stuff. If there are any any special considerations that will make the comparison to PVWatts easier, let me know.

[drdanley]

Most of this sounds good to me. Two points:

1. I am not sure how NOCT (Nominal operating cell temperature) fits into the calculation. NOCT is intended to represent a more realistic state of module performance – it is commonly used to describe system performance at 800 W/m2, 1.5 AMI and 1 m/s of wind speed. A slightly more accurate description of cell temperature is T_cell (degC) = T_amb (degC) + 25*irradiance/(1000W/m2). Since we have systems all over the country, using a fixed cell temperature of 45C would overestimate performance in hot climates and underestimate performance in cold climates.
2. Tracking – I agree that “ideal tracking” would seem to describe two-axis tracking. This is currently fairly rare among non-concentrating systems, but is sometimes used in smaller residential or commercial arrays, especially those used to “demonstrate” solar. (There are two single axis trackers at the Honda dealership in Germantown near where I live, and I have seen these trackers in front of a couple of co-ops I have visited.) Most “commercial” systems use roof mounted arrays, which are usually fixed low tilt, non-tracking systems. The main place that trackers are used is in large systems (each motor drives approx 300 kWp) and these tend to be single axis trackers oriented either east-west or north-south. There is an ongoing debate about whether the extra energy (or the timing of energy) from these systems is worth the extra capital cost and maintenance. CEPCI in South Carolina is operating a large single axis tracker next to a fixed tilt array to try and shed light on this debate.
   • Doug

[trevorhardy]

1. NOCT is used by Gridlab-D in calculating the performance of the panel as the ambient temperature and sunlight irradiance change, just as you outlined in your comment. I included it in the list just so that it is explicitly defined rather than leaving future developers guessing as they try to improve the system and are working with the OMF and Gridlab-D code base. Gridlabd-D requires this value to be defined for the solar PV model and my thought was that having it clearly stated will save a little bit of work down the road. Defining NOCT doesn't fix the operating temperature of the cell but simply defines the normal operating temperature for the Gridlab-D solar model to use in its calculations.
2. I brought up single-axis tracking because I bet there is some interest in OMF users to explore these large types of installations where single-axis tracking might be used but currently Gridlab-D doesn't support this. I wanted to let everybody know that this was the case on the off chance we decided this functionality was important so we could plan accordingly.

[trevorhardy]

I've got a very simple test solar panel installation and inverter up and running that we should be able to use for comparing the output to PVWatts. I've been informed by another developer here at PNNL that our solar model is based an the default algorithm in NREL's SAM software which may or may not be related to PVWatts. Regardless, I don't expect it will be difficult to get them lined up. As soon as we can nail down test conditions I can get to work. Even better, if the test conditions came with the output from PVWatts I should be able to match it quickly.

Skipping ahead to the "Nice To Haves"

• I've verified that if the inverter is undersized compared to the solar panel output that the output from the inverter is limited to its own ratings. We do get the clipping effect that Doug was interested in seeing.
• It is pretty simple to adjust the PF output of the inverter on a fixed schedule. I've tested it and, based on any time/calendar parameter, we should be able to set the inverter power factor to an arbitrary level.

[dpinney]

Thanks Trevor, this is a lot of good news.

Are you waiting for test cases? I think the following is a good minimum test set.

Minimal test cases:

1. Residential rooftop system: 5 kW DC panel max, no tracking, tilt/azimuth set to maximize energy output.
2. Residential 2-axis tracked system: 5 kW DC panel max, 2-axis (GLD's "ideal") tracking.
3. Small utility-scale system: 100 kW DC panel max, no tracking, tilt/azimuth set to maximize energy output.
4. Large utility-scale system: 500 kW DC panel max, no tracking, tilt/azimuth set to maximize energy output.

For all these, panel temperature coefficients should be -0.439%/°C, inverter should be 1.1*panel DC max rating, 0.99 leading PF, 96% efficient.

Regarding PVWatts, just use the latest version in SAM. The best we can do is just choose a version and test against that. I saw the PVWatts website recently updated and results are now 10% higher, so PVWatts is clearly a moving target.

SAM does have a python SDK, if you want to use that. In pvWatts.py we use it, for example.

Let me know what else you need.

[trevorhardy]

I think those conditions and test cases should be enough to get me going; thanks!

[trevorhardy]

I've been working with the Gridlab-D model this afternoon and haven't quite been able to get it to line up with SAM's PVWatts output. Here are the results from the first case (5kW residential rooftop).

The error is less typically less than 10% and is most pronounced around the afternoon peaks in the summer. SAM doesn't make as many modeling parameters available for adjustment so it is not easy to figure out where the differences are showing up.

Here's what case 2 (2-axis tracking) looks like:

The differences in the two models are clearer here and the percentage differences are slightly higher. There is also some variation at times in the shape of the outputs; nothing catastrophic but noticeable at times. Given that this isn't actually intended to be a two-axis model but ends up kind of acting like one, the differences don't seem out of line as compared to the fixed-axis results above.

Given that PVWatts is not canonical and the differences are relatively small, I think we could call this good enough for now and move on. Thoughts from the OMF side? Is this good enough or do we need higher correlation?

[drdanley]

I agree that this looks like a small difference in assumptions somewhere. I would be curious to see a zoom in on a single day -- perhaps one of the fixed axis days with double peaks. For now, this looks pretty good to me.

[dpinney]

I'm not the solar expert, but within 10% of the SAM results sounds great to me.

Trevor, when you're ready, could you upload your test files in to /omf/omf/scratch/solarSamComparison/?

This is coming together nicely.

[trevorhardy]

Files have been uploaded.

Its worth noting I did slightly adjust the "behind-the-scenes" to improve the correlation:

• efficiency = 0.155 (was 0.15)
• 75 ft^2/kW (was 66.67)

I also determined that the NOCT is not used in this version of the model so it can be removed.

All of this is shown in the .glm files in the solarSamComparison folder along with all the other specific parameter values.

[drdanley]

Just as a data point, a REC Solar 72 cell, 305 Wp module has an area of 21 Sq Feet. This works out to 68.7 sq feet per kWp and an efficiency of 15.6%.

[dpinney]

I think we're good. I'm going to close this and assume no one wants to log the "stretch goals" as GLD enhancements or try to come up with a plan around the "ultra-stretch goal".

[dpinney]

Reopening to look into the possibility of adding a data abstraction layer so OMF users can input kW for panels and Gridlab can get sqft.

[dpinney]

Just waiting on GLD 3.2, so closing.