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