Timezone field not affecting results

Hi Marty,

That checkbox is on the NSRDB website, not in SAM. I'm not sure how the NSRDB implements its time shifting calculations.

A SAM simulation usually involves a performance model and a financial model. The PV performance model reads the year, month, day, hour, and minute columns from the weather file to determine the sun position for each time step. That's why it is important for the solar resource data to be consistent with the time stamps -- so you can ensure that the sun position and solar irradiance values are consistent. The financial models don't read the time stamps, so they determine the date using the row number.

We hope at some point to align all of the models so they read time in the same way. That will make it possible to run simulations over irregular periods, or to start from months other than January. Because of the way the models have evolved over time, there is a lot of work to be done to achieve that.

Best regards,
Paul.

Hi Paul,

Thanks for the clarification. I'm actually only using the PV performance model, not the financial model. So if I understand you correctly, SAM calculates sun position using the Month, Day, Hour, and Minute columns, but it assigns a timestamp to the solar irradiance data based on row number. If the first row of solar irradiance data is always assigned to the hour that ends at 1 am on January 1, how would that data ever be consistent with a timestamp at 30 minutes? 

For instance, here is data with timestamps shifted from UTC -> IST: 
I could add 4 dummy rows at the top so that the first row corresponds to the hour 12:30 - 1:30 am on January 1. However, based on what you said earlier, SAM would still assign the first row to 12 -1 am. Alternatively, I could interpolate every two rows to manufacture data at the top of each hour, but then there'd be no use for the Minute column at all. What do you suggest?

Thanks again!
Marty

Hi Marty,

Here are the first few lines of a file with hourly data for a location in the UTC-8 time zone. The solar irradiance data is measured on the half-hour. The first time stamp is for 1/1/1999 0:30 local time, so the first row represents the hour ending at 1 am on January 1:



Here's another file from the NSRDB that contains 30-minute data for a location in UTC-7, with solar irradiance data measured at the top and bottom of each hour.  The first time stamp is for 1/1/2018 0:00 local time, and the second for 1/1/2018 0:30. The first row represents the first half-hour of the hour ending at 1 am on January 1:



Best regards,
Paul.

Hi Paul,

Thanks for the thorough clarification!

Marty

Here's a bit more on this.

Attached are two files that I downloaded by hand from the NSRDB for a location in India. For one, I checked "Convert UTC to local time", and the other I didn't.

For the file with time stamps in UTC, time zone = 0 and the minute column has zeros. For the file with local time stamps, time zone = 5.5 and the minute column = 30.

SAM does the equivalent of checking the box when it downloads files from the NSRDB -- it doesn't do any additional processing of the files.

Best regards,
Paul.