Standardize/update module efficiency calculations across all module models

[caseyzak24]

Currently, the definition of module efficiency (passed out of the module model as out.Efficiency and accessed as subarrayX_modeff) when using the mlm module model is inconsistent with the definition of all the other available module models.

In the mlm model, efficiency = output_power / (collector_area*poa_eff), where poa_eff is the total irradiance after module cover effects (in keeping with the output definitions in the latest release). In all other module models, efficiency = output_power / (collector_area*poa_shaded_soiled), such that the given module efficiency includes module cover effects.

A simple solution would be to change the implementation of the mlm model, but I think this brings up the larger question of how module efficiency should be defined in ssc/SAM. When I first used ssc I was surprised to find that efficiency was defined relative to poa_shaded_soiled, since other software (namely PVsyst) defines it relative to poa_eff. Also, defining it relative to poa_eff aligns with the way the name plate rating of a module is defined (it also does not consider angle of incidence effects).

I am sure there are good reasons to define it relative to poa_shaded_soiled, but I hope this request will eventually result in a standardization of the calculation.

[nickdiorio]

Thanks @caseyzak24 , you bring up some excellent points. We do have the plan to re-evaluate these calculations this year, in addition to breaking more losses out of module model. We'll definitely keep your recommendations in mind, and I agree that it would make sense if we align an efficiency definition across models.

[janinefreeman]

Great explanation @caseyzak24 . Assuming that it will take a while for various tools to agree on a definition of efficiency, I can see advantages to reporting either efficiency in the meantime. On one hand, being consistent with the definition reported by the other module models in SAM is helpful, but on the other hand, consistency with output values reported by pvsyst is arguably the primary reason this model option is used in SAM. I'd be curious to hear @caseyzak24 , @timorichert, and @cpaulgilman 's opinions on this question prior to merging in @caseyzak24 's fix for that particular line.

Thanks for starting an interesting discussion! :)

[caseyzak24]

@janinefreeman you bring up an interesting point; I hadn't thought about people expecting the output of the model to line up with PVsyst outputs...

Long term, I'd like to see the definition of efficiency across all module models changed to align with PVsyst, simply because it is the most clean definition of efficiency and it aligns with the calculation of nameplate capacity for modules. Or, perhaps, there should be 2 reported efficiencies, something like "cell conversion efficiency" and "module assembly efficiency".

Until that change is (hopefully) made, I would vote for consistency across module models as opposed to one model aligning with PVsyst. Our company uses different module models (namely ml and iec61853) for different technologies/purposes, so its important to be able to compare outputs across the different models.

I would also advocate for more elaboration in the SAM help so that users who may be confused about the efficiency values can find an explanation. I know I had to figure out the efficiency definition by looking at the source code.

[adriesse]

Interesting discussion. I prefer to calculate efficiencies myself using whatever power values from the model chain output that I deem appropriate for my particular analysis. That way I can be fairly sure I'm comparing apples to apples.

I think rather than try to aim for an agreed definition of "efficiency" it would be adequate and preferable to provide more descriptive names for whatever you calculate in SAM (or any other program for that matter).

[timorichert]

When I developed the code I was mostly aiming at consistency with PVsyst. I have to admit that it never occurred to me to look at the implementations in the other models. Great that you brought this up, @caseyzak24!

[...] Also, defining it relative to poa_eff aligns with the way the name plate rating of a module is defined (it also does not consider angle of incidence effects).

I understand that nameplate rating is defined in a measurable way, i.e. as realized in flash testing of modules. When a module is flash tested, by my understanding the incidence angle is zero and the module is clean per testing standards. So I guess in that case poa_eff equals poa_shaded_soiled, which is why there maybe isn't really a conflict of definitions. @caseyzak24, do you agree or am I getting something wrong here? But nevertheless, using poa_eff makes comparing the actual value for a given simulations state to a datasheet value easier and more consistent, even though this comparison is obviously flawed in itself.