Repository navigation
Support diffuse component-specific IAM in Array.get_iam() #2812
Description
Activity
Note: Just to keep The Tracking of Things™ fun,
perezreturns the diffuse circumsolar component, which is adjusted using the direct IAM :).Without thinking too hard about it, option 1 seems best to me, although I suggest considering keeping the method name
Array.get_iamas-is.Another API question is how diffuse IAM values should be returned. Should they be returned as a dict or DataFrame, keeping in line with the treatment of diffuse components in pvlib.irradiance?
Another not-thinking-too-hard +1 from me here.
Reacted by Rodrigo Amaro e Silvain line with @kandersolar keeping the original
get_iamname for the direct IAM and the diffuse transposition format in theget_iam_diffuseoutputs seems good to meReacted by Cliff Hansen and Adam R. JensenI think having
get_iam_directandget_iam_diffusecould be a bit clearer for the user thanget_iam/get_iam_diffuse, and could be managed by having a deprecation period forget_iamduring which it simply callsget_iam_direct. But if others are against this, I thinkget_iam/get_iam_diffuseshould be fine as long as the docstrings are clear.I can't quite visualize how all this is going to work, but don't let that stop you. Each irradiance component can be treated differently so maybe you could have a get_iam function that has an option to return components? (Just thinking out loud.)
@adriesse in this case components shouldn't be an option but rather the default, since diffuse IAM is always component-specific.
On the topic of
schlick, due to feedback on it not being a very useful model for PV modeling (see #2828 and #2832), I won't be includingschlick_diffusehere. However,schlickis tecnically an option viamarion_diffuse. Should theArrayclass explicitly preventschlickfrom being used here by throwing an error if the user attempts it?Reacted by Rodrigo Amaro e Silva- addedGSoCContributions related to Google Summer of Code.Contributions related to Google Summer of Code.
on Sep 11, 2026
This issue is intended to discuss the API for adding diffuse component-specific IAM calculations to the
Arrayclass.This is part of my GSoC 2026 project, more specifically, part of the second phase of the project, with the goal of adding support for diffuse components and component-wise IAM in
ModelChain. The plan is described in more detail in #2811.Once diffuse irradiance components are available from
Array.get_irradiance(),Array.get_iam()must also be updated to support diffuse component-specific IAM (isotropic sky, horizon, and ground). Currently, only direct IAM is returned.There are a few ways this can be done:
get_iamintoget_iam_direct(preserving the current behavior) andget_iam_diffuse(returning diffuse component-specific IAM)get_iammethod that can optionally return both direct and diffuse IAMget_iammethod that computes either direct or diffuse IAM depending on the requested argumentsPersonally, I am partial to the first option since the functionality of each becomes clearer to the user, but I believe there should be a consensus on this. It's worth mentioning that renaming
get_iam()is a breaking change and would need a deprecation period.Another API question is how diffuse IAM values should be returned. Should they be returned as a
dictorDataFrame, keeping in line with the treatment of diffuse components inpvlib.irradiance?