Translating from Power to Energy in Sunrise/Sunset Hours

[janinefreeman]

Currently in SAM, for sunrise/sunset hours, power is translated to energy for the entire hour, not just the portion of the hour where the sun is actually up. This was possibly an ok assumption when most irradiance data was hour-averaged, but using instantaneous data, this may be more inaccurate. There's very little documentation from other pv tools as far as what they are assuming to go from power to energy for these hours.

[janinefreeman]

@mikofski and @adriesse can I interpret your thumbs up emojis as agreement that we should change the assumption to assume power generation just for the portion of the hour where the sun is actually up? :)

[mjprilliman]

@williamhobbs would be great if you could weigh in as well.

[adriesse]

@janinefreeman I was mostly just encouraging the initiative. For a specific solution I would probably need a more detailed explanation or a formula.

[williamhobbs]

@mjprilliman and @janinefreeman, remind me, is this a fix for the suspected root cause of the issue we saw in the subhourly correction work for PVSC?

[mikofski]

I agree with Anton, I think context is useful.

if the sunrise time is known, then I think the average GHI energy during the interval containing sunrise would yield a lower incident flux if divided evenly over the entire interval versus assuming zero flux prior to sunrise (*) then dividing the GHI energy over the remainder of the interval. This larger incident flux might have a different conversion efficiency. Also other effects like IAM and tracker position would also differ if centered at the middle of the entire interval versus centered on the remainder of the interval after sunrise.

However, I have a feeling this wasn’t the question you’re asking.

now that you have an estimate of the output during the remainder of the interval after sunrise, should this be assigned to the entire interval or not?

in my humble opinion, yes, we should keep the intervals the same and make sure that we only use units of energy which doesn’t say exactly when that energy was produced only what the sum of all output over the interval was.

why? because this makes aligning the output with the input easier. The input and output are easier to work with if the intervals are the same size

(*note this may be a poor assumption because there will be nonzero diffuse light before sunrise and after sunset. A clearsky model can help approximate when diffuse light is nonzero. Also as the interval size gets smaller the effect of sunrise/sunset will decrease and just treating the entire interval as uniform is a good approximation. This discussion applies both to sunrise or sunset but the order of zero/nonzero is reversed.)

[cwhanse]

I think it would awkward if the energy output had irregular time steps at the beginning and end of each day.

[janinefreeman]

Thanks all for your thoughts! @williamhobbs yes, this is one of the issues that arose out of this work.

Further context- SAM calculates the sun position (and therefore all related incidence angles) at a given point during a time step. For hourly data, that's usually at the 30 min mark. For sunrise and sunset hours, though, the convention is to use halfway between (sunrise/end of hour) or (beginning of hour/sunset) for the timestamp of the sun position calculation (unless the exact minute to use is specified in the weather file). However, when we then translate the instantaneous power calculation to energy, this is problematic for the sunrise/sunset hours.

A worst case (totally fictitious) example- sunrise is at 6:50AM in an hourly simulation. We calculate instantaneous power at 6:55AM to be 10 kW. Currently, that would be translated into 10 kWh energy for the 6-7am timestep, when in reality it is probably closer to 1.7 kWh for that timestep.

The proposed fix we discussed at our SAM meeting yesterday is to scale the power value to be the average power over the timestep, so in our example, we would assume 10 min of 10 kW and 50 min of 0 kW, and assign a power value of 1.7 kW for the 6-7am timestep. This will maintain simplicity in subsequent energy summations (not having to treat sunrise/sunset timesteps differently than every other timestep), and we think should compare better to measured data, assuming that measured data is usually an average value over some time period (or measured data is actually energy, in which case the user is performing a unit conversion anyway).

The same principle would apply regardless of timestep, just using hourly data as the worst-case example.

The reason we're trying to maintain this in a power calculation, versus switching to energy, is that we need power values for downstream calculations in financial models (best example is demand charges for behind-the-meter systems offsetting a load with PV).

I think our proposed approach aligns with the comments I'm reading here, but appreciate any further input from our impromptu think tank 😄

[cwhanse]

we need power values for downstream calculations in financial models (best example is demand charges for behind-the-meter systems offsetting a load with PV).

Demand charges are frequently based on shorter intervals, e.g., SDGE uses 15 minutes.

I think it's better to leave power "unaveraged", that is, publish the point value that is estimated for each interval of time, along with the energy accumulated for each interval of time. With the average power, energy pair, the two numbers will always be the same (1.67kW, 1.67kWhr) for the example above. In contrast, 10kW power and 1.67kWhr energy provides more information, and enough to reconstruct what happened in the simulation.

[adriesse]

Would there be a difference between the calculations for period-averaged weather data vs. instantaneous?

[janinefreeman]

@cwhanse I agree that it would be best to separately show power and energy outputs. However, that requires massive refactoring of all of our financial models, so for this release we were hoping for something "less bad" than the current approach, although still not ideal. I think we could consider that kind of refactor for a future release, though.

@adriesse Great question. We currently attempt to address that with the way the timestamps are formatted- for hourly data, if there is no minute column in the weather file, we treat it like averaged data (doing sun position calculations at the midpoint of the timestep, or the midpoint between [sunrise/end of hour] and [beginning of hour/sunset]), and if there is a minute column, we do calculations at that point in time. For subhourly data, we rely on users to specify the minute column such that it is most representative of the data measurements- at the midpoint of the period for averaged data, or exactly when the measurement was taken for instantaneous data. Past this issue of timestamp for computing sun angles, the two are treated the same in SAM. I'd love to add a flag to the meta data specifying averaged or instantaneous data. We did work with NSRDB to ensure that when their data switched from averaged to instantaneous, they started using the X:30 image to create the TMY (rather than right on the hour) so that it will align better with hour-averaged data.

[adriesse]

A worst case (totally fictitious) example- sunrise is at 6:50AM in an hourly simulation. We calculate instantaneous power at 6:55AM to be 10 kW. Currently, that would be translated into 10 kWh energy for the 6-7am timestep, when in reality it is probably closer to 1.7 kWh for that timestep.

This case arises only when you have hourly average irradiance input, right? If you had had instantaneous values you would probably have had zero irradiance at 6:30 as input for the hour. So if the average irradiance for the sunrise hour produced 10 kW, then 10 kWh seems like the right energy.