<< Click to Display Table of Contents >> Navigation:  Meteo Database > Notes on Meteo > Meteonote7: Time shift in imported meteo files

PVsyst conventions

In the PVsyst convention, the time label always refers to the beginning of the record, and concerns the accumulation up to the next record.

The time is itself defined in Legal Time for the concerned site (according to the Time Zone), and doesn't vary according to the DST (it is usually for the Winter time).
 

External imported data files

Now with imported data files, there is no general rule.

Each record usually holds a time label, which possibly doesn't correspond to the PVsyst definition.

Moreover, this time label may represent data measured (averaged)  over a time period which doesn't correspond to the true Legal Time "round" hours.

 

Depending on authors or data acquisition systems, this time label definition may be:

-  The time periods may also be defined in sub-hourly values, which will be averaged in hourly values at the importing time.

 
Time Shift  correction

Now for treating these meteo data, PVsyst has to determine the time at which the Solar Geometry will be computed.

In order to avoid model's errors, this time should be the exact middle of the averaging period for one hourly measurement.

In PVsyst, this is achieved by a particular parameter of the Meteo file, the Time Shift, which is the time difference (in minutes) between the effective calculation of the solar geometry, and the PVsyst usual definition (i.e. the half-hour).

This Time Shift will be used in any calculation involving the hourly meteo (e.g. the simulation).

NB: When displaying these shifted data (tables, graphs), PVsyst will always keep its "full hour" labels. The Time shift is "forgotten" in the results.

 
Effect on the results

The correct time is extremely important, especially for the Transposition model, and also for the Diffuse model.  

As these models are already used during the import of the data, it is very important to define the parameters governing the time already during the Importing process,

With POA imported values, observing this rule is fundamental, as the (retro-) transposition of the hours in the morning or the evening are very sensitive to the Sun's height (division by sin(Hsol), i.e. the time at which it is computed.  

A time shift error in the solar geometry will result in very high errors for the Horizontal Global value (may attain several kW/m²), which is of course quite unphysical, or even lead to POA significant values for HSol = 0°.

This is the main (only) source of discrepancy between your input measured data, and the effectively re-transposed values in the same plane orientation.

If you observe such discrepancies, you are advised to have a look on your data in hourly values  ("Meteo Tables and Graphs > Tables" tool),  and observe the discrepancies either in the morning, or in the evening, between your measured input data ("Global measured" and the recomputed values ("Global Tilted plane").

With global horizontal values, the diffuse model also uses the solar geometry. In case of discrepancy, you will observe an asymmetry between morning and evening in the modeled diffuse for clear days.  

 
Time shift correction when importing data

PVsyst offers several tools for the evaluation of the time shift (either  by comparison to the clear sky model, or using the Hourly Kt morning/evening graph).

Therefore when importing an unknown data set (especially with GlobInc/POA  or unpecified diffuse):

- First import the data without precautions. The program will guide you to the graphs for the assertion of the correct time shift.

- Evaluate the effective time shift of your data.  

- Apply the observed time shift corrections in the format protocol, and re-import the data.

If the effective time shift is less than +/-30 minutes (*):

- With the general  ASCII importing tool, you should specify the "Time shift" parameter in the importing protocol.

- With PVsyst standard files, you can add a line   #Time shift   and the value in minutes  in the header

- With other sources, you don't have the opportunity of changing the time shift at the import time, but you can adjust it for the future uses of the MET file. Usually the "known" files imported by "Import Meteo Data" are already corrected in the importing protocol.

If the effective time shift is more than +/-30 minutes (*): you have several means for the correction:

- With the general ASCII importing tool, you should specify the "Hour shift" parameter in the importing protocol.

- With PVsyst standard files, you can add a line #Hour shift   and the value in hours in the header

- With other sources imported by "Import Meteo Data", if this arises, it is usually not a file compliant with the usual definitions of the concerned source.

- With all files, you can also modify the Time Label directly in the source file, by displacing the Time label column (in EXCEL, insert or delete one cell at the beginning of the column).

If there is a time shift varying along the year:

- With the general ASCII importing tool, consider using the DST correction  (option "Summer Time > Apply").

- Otherwise there is no practical way, except modifying the dates directly in the source file.  

If the file is written in UT (Universal Time):

- With the general ASCII importing tool, check the box "Universal time".

- With PVsyst standard format, you can add a line #Time Reference with the value  UT

 

 

NB: In PVsyst,  the time defined around sunrise and sunset for solar geometry is the middle of the interval when the sun is over the horizon.

NB: When importing data (especially from POA), PVsyst will limit the GlobHor  to a reasonable value according to the clear sky model. This is the main cause of the discrepancy often observed between  the POA original values and the transposed values.

(*): The true limit is specified by the Hidden parameter 'Maximum allowed time shift in Meteo data', under the category Miscellaneous : Meteo, Simulation
 

The following diagram summarizes the necessary steps for importing data from a custom or unknown data file.