Why the "percentage of surface area" option is removed from the Generator PV component

May I ask why the “percentage of surface area” option, i.e., “_SASolarCell” is removed from the latest Generator PV component?

The red component shown below is the old PV component.


I am also curious why it was removed and how the value is now calculated as it seems the read me still outputs the surface area percentage as changing with the efficiency… Trying to learn pv analysis by following these tutorials… https://www.youtube.com/watch?v=kQH_z2_tDWM

thanks -E

Hi Guys,

Sorry for the delay in getting back to you both I re-wrote the code so that the % of area that the cells cover of HB surface that the cells are mounted on is automatically calculated for the simple mode according to the equation:

% surface covered by solarcells = (poweroutparallelseries)/(irradiancesurface areacellefficency)


  1. Irradiance is 1000 W/m2 as this the irradiance that panels are rated under

  2. Surface area: Is the surface area of the HBsurface

For the Sandia mode the area is automatically taken from the input panel.

Warnings will be thrown if the calculated area that the cells cover is greater than 85% of the HBsurface

I thought this would be cleaner than having to manually input the area, let me know if you are still confused or have any questions

Hi Ethan,

My apologies I didn’t update the tutorials to include this change, in your opinion do you think that I need to?

Hi @AntonSzilasi -
In playing around with the PV Gen component, there appear to be a few oddities. It seems that the formula used to calculate generator area is: generator power x 1 kW/m2 x cell efficiency. I recognize that this is also the formula that PVWatts uses. However, there are a few problems with these assumptions.

First, I don’t think that the cell efficiency should be linked to the calculation of power per surface area. According to the E+ I/O Reference, the cell efficiency field “specifies the efficiency with which solar incident energy is converted to electricity.” Theoretically, this could be anything and would not affect generator size.

Second, as used in this context 1 kW/m2 is not the irradiance that panels are used under, it is the power output per area of panel. Most panels on the market have much higher values than 1 kW/m2. See, for example, this reference. I believe this input should be able to take any arbitrary number as a power per area input. However, in the HB component, it has been capped at “100%” of the calculated surface area based on the 1 kW/m2 hard limit. I think this is an unrealistic assumption. Would it be possible to remove this limit?

Third, I agree with others that the % of surface area input was a useful input. Would it be possible to bring it back?

Thanks for your help and apologies if I’m misunderstanding any of this.

@Burin, I agree with your opinion, and I think cell efficiency and PV coverage of a surface can be two parameters of a PV surface independent to each other.

What do you think, @AntonSzilasi ?


@Burin @Grasshope thanks for your input gentlemen. I did write this code a while ago and I’m struggling to find the time to do a complete re-write.

Would you guys be interested in working with me to update these components? The beauty of Honeybee is that if you can write some python you can do whatever you want.

@AntonSzilasi, I suggest you put some time to document your code as much as you can so others can help or fix the code if needed. As we discussed before we need to integrate this functionality into OpenStudio moving forward and that’s when we will need the documentation even more.

@AntonSzilasi - Unfortunately, I am useless at coding, even with Python. However, I can help with the E+ part of things. I’m copying below the minimal classes necessary for a functional PV system. I’ve boldfaced the IDF variables that I feel would be useful inputs for the HB components. For the not bold variables I’ve indicated the defaults that I typically use.

By the way, I think you’ve implemented most of this already. I think that the task is to simplify the code by removing the Power/Area assumption.

!- Name
!- Surface Name: Assigned geometry surface name
!- Photovoltaic Performance Object Type: PhotovoltaicPerformance:Simple
!- Module Performance Name: PV
!- Heat Transfer Integration Mode: Decoupled
!- Number of Series Strings in Parallel {dimensionless}
!- Number of Modules in Series {dimensionless}

!- Name: PV
!- Fraction of Surface Area with Active Solar Cells {dimensionless}
!- Conversion Efficiency Input Mode
!- Value for Cell Efficiency if Fixed
!- Efficiency Schedule Name

!- Name: PV List
!- Generator 1 Name: Auto-Reference Generator Name
!- Generator 1 Object Type
!- Generator 1 Rated Electric Power Output {W}
!- Generator 1 Availability Schedule Name
!- Generator 1 Rated Thermal to Electrical Power Ratio: Blank

Dear @AntonSzilasi @Burin @mostapha,

My Python programming is rusty …

I understand the fail-proof safety mechanism built into the current PV generator component to prevent unrealistic specification for PV modules and PV system.

I think it’s still very useful even without major code overhauling.

For example, the attached workflow is created to work with the calculation of PV coverage ratio for a surface specified to install PV as shown below based on my understanding of Anton’s note:


It includes the considerations of:

  1. multiple input surfaces to install PV
  2. realistic standard PV module parameters
  3. arbitrary max allowable PV coverage ratio
  4. automatic resizing of PV module power output based on the size of the PV installation area
  5. creation of transmittance schedule for each PV install region taking into account PV converage and the gaps between them, in case translucent PV module is used

workflow to specify PV surface _v001.gh (511.3 KB)

… one irrelevant question is that, in the example workflow, why the name of the shading surface is still the automatically assigned one rather than the one I specified through the HB Surface component ? …

@Grasshope, Nice work on summarizing things! I automatically asign the shading surface name to make less room for error!

I’m actually starting to make an attempt with my free time to start moving the code over to the export to OpenStudio component since the the run E+ is now obsolute

Post note - those tutorials are extremely old and I am taking them down because Im sure that they are more confusion than they are worth. I am currently in the process of integrating the PV functionality into the export to OpenStudio component

Noted with thanks, @AntonSzilasi.

The default name for shading surface is a very long string which is difficult to search or retrieve results of, for example those defined as PV surfaces. (e.g. the one highlighted in the image below)

It would be great if customized surface name can be accepted in the component.


Unfortunately this is the way that context surfaces have to be defined as the name must aways be unique and thus we must use a guid. @mostapha I believe that I am right here correct?

Can’t you use the E+ jump dropdown?

@Grasshope @Burin
Also please see the latest re-work of my code here: https://github.com/mostaphaRoudsari/honeybee/pull/679 (Down load the honeybee latest code)

I now have the PV generators in the OpenStudio component and I will be adding the batterys and the wind turbines in the next few weeks. Unfortunately I had to remove the functionality in the E+ component as it was too difficult and in-consistent to maintain both the E+ and the export to OpenStudio component.

Let me know how this works with your workflow - lets work together to ge this thing working

Thank you, @AntonSzilasi, for the update.

I tried the updated PV generator component for the ExportToOpenStudio component.

There seems to be two issues:

1. number of shading surface
An error of “-1” is reported when multiple shading surfaces are connected to it:

2. missing output variables
The three total building electricity related output variable as requested are not reported at all (see image below), so does the output variable Electric Load Center Produced Electric Energy, which can be reported using the previous PV Generator component for E+. (I’m not sure if it is an issue of the ExportToOpenStudio component. Hope @mostapha can kindly advise in this regard.) :


3. unit
Although it is specified to use kWh for the output, it is not registered in the IDF file, and the html output file is still reporting in the unit of J. (Again, not sure if it is an issue of the ExportToOpenStudio component) :


4. integration mode
It seems the integration mode option is not available anymore… May I ask if it is critical, or shall we keep the option?

So, for the time being, I have to stick to your old PV Generator component for the E+ component to get the output I want.

The test file is attached for your reference.

Hope you can kindly take a look and advise.


PVGen4OpenStudio_test_v003.gh (651.9 KB)


Thanks for diving deeper - as for one point 1. I cannot reproduce it can you attach another GH file with this error?

  1. I am also surprised that generators shows up as zero in the html file I am not really sure why - I have added two more outputs here which I thought that would fix this but surprisely they havent.

See this here: https://github.com/mostaphaRoudsari/honeybee/pull/680

At least now I see generators being registered in the Annual and Peak Values - Electricity table though so thats an improvement.

I am not sure what table I am looking at in the Image 9.png nine… where did you get it from?

  1. I am not sure I think EnergyPlus just works this way.

  2. Yes I have removed it I will only be supporting the most basic generator functionaliy from now on (batterys and wind turbines will be added when I find some time). If you want functionaliy beyond that you will need to learn to code ; )

To address 2 and 3 I suggest that you take a look at the EnergyPlus example file for PV (under example files in the PV folder) or ask on unmet hours perhaps I am not getting the outputs quite right. If you can guide me what outputs are really needed we can fix this issue together.

PS: It maybe easier for us to talk on gchat to work this stuff out - ajszilasi@gmail.com
PSS: Also find the GH file with the new outputs for point 2 (in export openstudio component) attachedPVGen4OpenStudio_test_v003 AJS.gh (660.2 KB)

Thank you very much, @AntonSzilasi.

To reply your replies:

I got the error of “-1” when connecting two arbitrary shading surfaces to part of the workflow specifying the PV surface in the example GH file i posted above:

The following are the output variables related to generator that I’d like to obtain so that I can read them in another workflow to visualize E+ output : EnergyPlus SQLite Data Viz in Tableau

Output:Variable,*,Generator Produced DC Electric Power, hourly;
Output:Variable,*,Generator Produced DC Electric Energy, hourly;
Output:Variable,*,Generator PV Array Efficiency, hourly;
Output:Variable,*,Generator PV Cell Temperature, hourly;
Output:Variable,*,Facility Total Surplus Electric Energy, hourly;
Output:Variable,*,Facility Total Purchased Electric Energy, hourly;
Output:Variable,*,Facility Total Produced Electric Energy, hourly;
Output:Variable,*,Facility Net Purchased Electric Energy, hourly;
Output:Variable,*,Facility Total Building Electric Demand Power, hourly;
Output:Variable,*,Facility Total Building Electric Demand Energy, hourly;
Output:Variable,*,Facility Total HVAC Electric Demand Power, hourly;
Output:Variable,*,Facility Total HVAC Electric Demand Energy, hourly;
Output:Variable,*,Facility Total Electric Demand Power, hourly;
Output:Variable,*,Facility Total Electric Demand Energy, hourly;
Output:Meter, Electricity:Building, hourly;
Output:Meter, ElectricityNet:Facility, hourly;
Output:Meter, ElectricityPurchased:Facility, hourly;

The following are the two posts on UnmetHours in which I asked about the relationship between generator related output variables, and Julien Marrec has provide his advice accordingly:

The image showing the output variables is obtained from SQLiteStudio which I use to read the in.sql SQL database file generated from E+ simulation by adding the following line in the IDF file:

Output:SQLite, Simple;

The SQLite database file presents the E+ output data in a structured way through several tables related to different types of key information, such as output variables list and keys, zones, surfaces, etc.: eplusout.sql

The following line of code in the “old” runEnergySimulation component converted the unit in the html output file to kWh, and I’m unable to find it in the exportToOpenStudio component, and maybe this is why the unit is still J or GJ. However, I assume this line can be added as an additionalStrings_ to the exportToOpenStudio component, if including it as one of the simulationOutputs_ is not working:

Thanks for covering the basic functions of the PV generator. Looking forward to trying the battery and wind turbines functions.

Hey @Grasshope !!

Were you able to solve your problem 1?
When I was using HB v. 0.62, my PV generation system worked fine, but when I updated HB to v. 0.63, I started getting this error (in my model and in the model available in hydra.github too:

Once, it seems that the code for PV is being exported to OS, and my “Export to OS” component doesn’t work because a PINVOKE error, I uninstalled HB 0.63 and moved back to v. 0.62.
However, I am also getting this same error as you in v. 0.62, even if I connect only one shading surface…


Please try this GH script with the latest update. It should work fine !