Should we change the nominal time zone to be its real time zone in the weather data

  • Harry Han
  • Topic Author
More
30 May 2016 06:41 #4452 by Harry Han

In China all areas are using the same time zone (time zone of BeiJing +8) as its nominal time zone, however, it will result that the real time zone in western China has two hours deviation (+6) from its nominal time zone (+8). Should I change the time zone and its hourly data to be its real time zone and hourly data (+6) in weather data.scv or just remian its nominal time zone and hourly data? The results are completely different when using these two kinds of weather data files.

Thank you very much for your answers!

Please Log in or Create an account to join the conversation.

  • ozsolarwind
More
30 May 2016 07:27 #4453 by ozsolarwind
The timezone is solar time. "Timezone. The location's time zone, relative to Greenwich Mean Time (GMT)." ( www.nrel.gov/analysis/sam/help/html-php/index.html?weather_format.htm#srw )

Please Log in or Create an account to join the conversation.

  • pgilman
More
31 May 2016 12:06 #4454 by pgilman
Dear Harry,
SAM assumes that the first time step in the weather file is for the one that begins at 12:00 am, local time. As SAM steps through each row of the weather file during a simulation, it calculates the plane-of-array irradiance for the row from the irradiance values for that row. It also calculates local solar time and sun angles for that row from the time stamp data (year, month, day, hour, minute) in the row and time zone in the header.
The time zone should be consistent with the irradiance data. For example, the irradiance data in the Urumqi, China weather file that is part of the SAM solar resource library peaks each day around the 14th hour of the day. The time stamp for that hour in local time is 2 pm GMT+8. If you change the time zone to a more reasonable GMT+6, the plane-of-array irradiance will still peak around the fourteenth hour of the day following the solar irradiance data in the weather file, but SAM will calculate the incidence-angle losses for that time step using local solar time calculated for 2 pm GMT+6, causing the difference in system output that you are observing. That effect is most visible during the first and last hours of the day when the sun is low in the sky.
If you did change the time zone in the header, you would also need to shift the solar irradiance and weather data.
I created the following graphs in SAM for a horiziontal PV array using the Urumqi, China weather file with the standard GMT+8 time zone, and again with the time zone changed to GMT+6. I added the red dotted line to show where SAM assumes Noon is based on the row number. In the GMT+8 case, the solar irradiance from the weather file and calculated sun zenith angle are aligned with each other, although the irradiance peak is around 2 pm. In the GMT+6 modified case, the You can see that the irradiance data and sun zenith angle are offset from each other because of the difference between the time implied by the row number and the time determined by the Year/Month/Day/Hour/Minute in the time stamp data for the row.

Best regards,

Paul.
 

Please Log in or Create an account to join the conversation.

  • Harry Han
  • Topic Author
More
31 May 2016 19:05 #4455 by Harry Han
Thank you ozsolarwind! I had read this in the help file, however I was not aware enough!
Thank you very much!

Please Log in or Create an account to join the conversation.

  • Harry Han
  • Topic Author
More
31 May 2016 19:40 #4456 by Harry Han
Thank you Paul!

Your response is really helpful and thorough!

I also tried this in SAM by using the power tower model. The results shown that the heliostat field patterns had changed with different time zones and their related hourly weather data. (I have shifted the solar irradiance and weather data in the new weather file). For the GMT +8 case, the opening of the heliostat field is facing to the south-east direction while to the GMT +6 case, the opening is facing to the south direction. Meanwhile, the number of the heliostats is also changed.

So, I think the time zone (and the rows in the weather file) must be changed to its local time zone in the calculation later on. I hope I get the right answer. Am I right?

Thank you Paul!
Best regards,
Harry Han

Please Log in or Create an account to join the conversation.

  • pgilman
More
01 Jun 2016 10:54 #4457 by pgilman
Dear Harry,
Yes, that makes sense.
I found this interesting blog that discusses a map of the world showing the difference between local time and solar time:
blog.poormansmath.net/the-time-it-takes-to-change-the-time/
On a related note, in some locations a nearby mountain range, or a weather pattern such as regular morning fog or afternoon thunderclouds to the east or west may cause the optimal orientation to be east or west of south.
Best regards,

Paul.

Please Log in or Create an account to join the conversation.

Moderators: pgilman
Powered by Kunena Forum