Skip to content

Support diffuse component-specific IAM in Array.get_iam() #2812

Description

@cbcrespo

This issue is intended to discuss the API for adding diffuse component-specific IAM calculations to the Array class.

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:

  • Split the existing get_iam into get_iam_direct (preserving the current behavior) and get_iam_diffuse (returning diffuse component-specific IAM)
  • Keep a single get_iam method that can optionally return both direct and diffuse IAM
  • Keep a single get_iam method that computes either direct or diffuse IAM depending on the requested arguments

Personally, 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 dict or DataFrame, keeping in line with the treatment of diffuse components in pvlib.irradiance?

Activity

  1. markcampanelli commented on Jul 7, 2026

    @markcampanelli
    Contributor

    Note: Just to keep The Tracking of Things™ fun, perez returns the diffuse circumsolar component, which is adjusted using the direct IAM :).

  2. kandersolar commented on Jul 8, 2026

    @kandersolar
    Member

    Without thinking too hard about it, option 1 seems best to me, although I suggest considering keeping the method name Array.get_iam as-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.

  3. ramaroesilva commented on Jul 30, 2026

    @ramaroesilva
    Contributor

    in line with @kandersolar keeping the original get_iam name for the direct IAM and the diffuse transposition format in the get_iam_diffuse outputs seems good to me

  4. cbcrespo commented on Jul 30, 2026

    @cbcrespo
    ContributorAuthor

    I think having get_iam_direct and get_iam_diffuse could be a bit clearer for the user than get_iam/get_iam_diffuse, and could be managed by having a deprecation period for get_iam during which it simply calls get_iam_direct. But if others are against this, I think get_iam/get_iam_diffuse should be fine as long as the docstrings are clear.

  5. adriesse commented on Aug 3, 2026

    @adriesse
    Member

    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.)

  6. cbcrespo commented on Aug 5, 2026

    @cbcrespo
    ContributorAuthor

    @adriesse in this case components shouldn't be an option but rather the default, since diffuse IAM is always component-specific.

  7. cbcrespo commented on Aug 5, 2026

    @cbcrespo
    ContributorAuthor

    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 including schlick_diffuse here. However, schlick is tecnically an option via marion_diffuse. Should the Array class explicitly prevent schlick from being used here by throwing an error if the user attempts it?

  8. added this to the v0.16.0 milestone on Sep 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    GSoCContributions related to Google Summer of Code.enhancement

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions