Repository navigation
Consider updating pvlib.tracking.singleaxis() to return zeros (or similar) for nighttime instead of NaNs #2539
Description
Activity
It depends on the variable. In this case NaNs make sense because the algorithm cannot calculate the optimal angle under these conditions, and I would think those NaNs are best processed downstream.
@adriesse, it makes sense to return NaN from the perspective of returning an optimal surface orientation. I'm not sure the docs for
pvlib.tracking.singleaxismake it clear that this is the goal of the function, though. It seems reasonable to me to allow the function to have a night stow position.At a minimum, I think the docs should clarify that it will return NaNs at night (hopefully I didn't simply miss that already being there...).
As far as NaNs being processed downstream, it seems that should be at least addressed in the modelchain, e.g., as used in the google groups example linked above. But I don't ever use modelchain, so I coul dbe missing something.
@williamhobbs, a stow capability could reasonably be added to the function, as you say. Either way a small update to the docs would help.
Reacted by Will HobbsIn general, the tricky part with setting all NaNs to something else is that the NaNs may have different origins, and you may not want to fill them all. A gap in measured data should probably not be filled, or may need special filling logic. In this case, there is no good reason to have a gap in sun position data, so the fillna() should be fine.
I'm +1 for a
night_stowargument, perhaps default of0., that is set based on only the zenith angle.I don't think I'd want to just apply
fillnaunless there was a clear use case as I would rather respect the convention of NaN in --> NaN out.Reacted by Cliff Hansen, Will Hobbs, Anton Driesse, Mark Mikofski and Adam R. JensenGood points about NaN in --> NaN out.
Should a new argument be something like
night_stow_thetato be explicit about what the value is? And would it be up to the user to passnp.nanif they wanted to preserve the current behavior?NaN in --> NaN out.
I guess that's what I was trying to say in a round about way. :)
Reacted by Will HobbsShould a new argument be something like night_stow_theta to be explicit about what the value is? And would it be up to the user to pass np.nan if they wanted to preserve the current behavior?
night_stowornight_stow_anglefor me. Passingnp.nanshouldn't be prevented, but I would favor a default of0as @wholmgren suggests.night_stowornight_stow_anglefor meI prefer
night_stow_anglefrom those two options.night_stowmight not be descriptive enough: it could be boolean or something else. Docs could clarify that it uses the same convention as thetracker_thetaoutput.I would favor a default of
0Same for me.
Reacted by Adam R. JensenIt might be good to have consistency between the naming of the output numbers and the night-time default number.
@adriesse, assuming I understand what you are suggesting, I agree. Because there are a lot of "angle" variables as inputs and outputs, and I frequently see angle definitions and conventions be confused by users, I like descriptive variable names, even if they are long and a bit ugly.
Something like
night_stow_tracker_thetawould be very descriptive, for example.night_stow_anglecould be assumed to be an underdefined "surface tilt" that doesn't specify azimuth. Docs can clarify, of course, either way.Something like
night_stow_tracker_thetawould be very descriptiveBecause the output rotation angle is
tracker_theta- if I didn't know that I wouldn't know what "tracker_theta" meant innight_stow_tracker_theta. Too bad we didn't name the outputrotation. But as you note, the key is to clearly define the parameter in the docs.I didn't have a concrete suggestion earlier. Now I'm thinking
tracker_thetaandtracker_theta_night. I guess the other three outputs can be calculated during the night as well then.Reacted by Will Hobbs+1 for defaulting to a stow angle to avoid nans at nighttime.
It trips up participants during tutorials, see my latest thoughts here: PV-Tutorials/2026_pvlib_tec_de_monterrey#1
Reacted by Will Hobbs, Echedey Luis and Mark Mikofski
Is your feature request related to a problem? Please describe.
pvlib.tracking.singleaxisreturns NaNs for intervals where the sun is below the horizon. This can result in NaNs propogating to lots of other pvlib outputs and can cause confusion, other issues, etc. See https://groups.google.com/g/pvlib-python/c/ZeVmTC7eddY as an example.It appears to happen here:
pvlib-python/pvlib/tracking.py
Line 155 in 6dfeaf8
Describe the solution you'd like
Perhaps change the default to be zero for surface_tilt and tracker_theta (and whatever is most appropriate for aoi and surface_azimuth). Or have an optional input for
pvlib.tracking.singleaxisto specify whether it returns NaNs or numbers at night.Describe alternatives you've considered
Applying
.fillna(0)(or similar) to the output ofpvlib.tracking.singleaxisis what I typically do.Additional context
It looks like this zero vs nan situation was briefly discussed in #569. It seems it would be worth further discussion. Is there a significant reason that NaN is the output at night?
fillna(0)is used in the gallery here and here, but not here.Tagging @cwhanse.