【How to Configure Weather Data in PVSyst｜Understand the Basics in 7 Minutes】

Table of Contents

• Why meteorological data settings are important

• Types of meteorological data to grasp before configuration

• Basic configuration workflow starting from monthly data

• Considerations when importing hourly data

• Consistency checks to always perform after configuration

• Common mistakes and how to address them

• Practical tips for improving accuracy in operations

• Summary

Why Weather Data Settings Are Important

In the analysis of solar power generation, conditions such as solar irradiance, air temperature, and wind vary on an hourly basis, and power generation and losses are calculated based on those variations. In other words, meteorological data are not mere reference values but input conditions that drive the simulation itself. Even if the design conditions are correct, if the meteorological data's location, timing, or granularity do not match, the expected accuracy will not be achieved.

In practice, it is common to pick data that seems close to the planned site and proceed with calculations as-is. However, even locations that appear nearby can have different radiation environments and temperature conditions depending on whether they are coastal or inland, on flat land or in mountainous terrain, or have differences in elevation. Differences in power generation will, of course, show up numerically, and they will also cascade into comparisons of azimuth and tilt, evaluations of shading, and decisions about overloading.

For this kind of software, the basic approach is to store monthly weather information as site data and then perform detailed calculations using hourly weather files based on that. In other words, instead of being reassured by looking only at monthly values, it is important to be aware of which hourly data are ultimately used for the calculations. Monthly data are the entry point, and the core of the detailed analysis lies with the hourly data.

Also, weather data is a major source of uncertainty. Even if you carefully refine settings for cable losses and conversion losses, if the original weather data are low-resolution, the reliability of the results won’t improve as much as you expect. Precisely for that reason, weather data settings should not be postponed but treated as a task to establish direction at the early stage of a project. Simply getting this right at the outset will make subsequent comparisons and evaluations much easier.

Types of weather data to be aware of before configuration

First, what you should understand is that meteorological data come in monthly data and hourly data. Monthly data summarize representative values for each month and are suited to grasping the basic climatic tendencies of a location. On the other hand, hourly data contain hour-by-hour variations in solar irradiance and temperature and are used for detailed calculations in power generation simulations. Beginners tend to proceed while leaving this difference vague, but simply distinguishing between the two makes the meaning of settings clear.

As monthly data, the minimum items to be aware of are global horizontal irradiance and outdoor air temperature. In addition to these, having diffuse irradiance and wind speed makes it easier to model under more realistic conditions. More input items are not necessarily better, but you should be clear about what is actually measured, what is gap‑filled (supplemented), and what is estimated. In practice, data with the same site name can differ in their composition, so it is important not to judge solely by the name.

In time-series data, it is important not only whether values are present but also which physical quantity they represent. For example, the approach to conversion changes depending on whether you process based on global horizontal irradiance, include diffuse irradiance, or use values from a tilted surface. If you import this ambiguously, you are likely to get unnatural results in morning and evening behavior and in surface conversions.

Even more important is the location information. Settings for latitude, longitude, elevation, and time zone directly affect solar position calculations and temperature conditions. What is easily overlooked is that the location where meteorological data were obtained and the location actually being planned may not be exactly the same. Using data from a nearby site is not uncommon, but in such cases you must evaluate validity not only by distance but also by terrain and elevation differences.

Another point to watch is how you handle the horizon and mountain shadows. If you leave it unclear whether monthly meteorological data already includes the effects of distant shading when making settings, you can end up double-counting those shading effects. Conversely, if you ignore shading settings entirely just because the observations appear to be affected, you will not reflect the terrain conditions of the project site. In practice, the basic approach is to be aware of what is incorporated in the meteorological data while managing terrain conditions separately and treating them carefully.

Basic setup workflow starting from monthly data

When setting up meteorological data for the first time, it's easier to follow the workflow if you first define a location and then organize monthly data for that location. The "location" here is not just a name, but an analysis reference point that includes latitude, longitude, elevation, and time zone. Confusing the project name with the observation site name can lead to problems later, so it's easier to manage if names are standardized and clearly meaningful to anyone.

Once you have defined the location, check the monthly meteorological values corresponding to that location. If there is a nearby site in an existing database, it is common to use that as a basis. However, even if you find a nearby site, don’t adopt it unconditionally; briefly check the elevation difference with the project site, whether it is coastal or inland, the degree of topographic exposure, and snow accumulation tendencies, as this can reduce rework later.

Even if you only have monthly data on hand, that does not mean you cannot set things up with it. Detailed calculations are performed using hourly data, so the workflow involves generating an hourly time series based on the monthly values. It is important to understand that monthly values represent average conditions and do not directly reflect the actual conditions of any given year. They are useful for initial assessments and rough estimates, but as a project’s accuracy requirements increase, comparison with hourly data becomes necessary.

When entering monthly values, it is basic to check the units and the order of the months mechanically. Misinterpretation of units, incorrect ordering of months, and different handling of decimal points are elementary yet very common mistakes. Especially when transcribing from external tables, checking not only the annual total but also whether the shapes of the summer and winter peaks look natural makes it easier to spot anomalies. That numbers have been entered and that they show natural seasonal variation are separate matters.

Also, when manually entering monthly data, it is not recommended to reduce values by hand in anticipation of the effects of mountain shadows or surrounding shading. The effects of shading should properly be handled separately as horizon conditions or surrounding conditions. Applying arbitrary adjustments to monthly values makes it difficult to trace later what was reflected and where. If you want reproducible settings, it is important to keep meteorological data as meteorological data and shading as shading.

Even after generating hourly time series from monthly values, it is safer not to consider the work finished. The generated hourly data are created to match the monthly average conditions, but they are not intended to reproduce measurements from individual days. Even when regenerated from the same monthly values, the hourly series may not be exactly identical and the results can shift slightly. Therefore, in practice it is easier to manage by assigning different roles to cases used for rough estimates and cases used for comparative analysis.

Considerations When Importing Time-Based Data

If you prioritize accuracy in real-world projects, you can't avoid incorporating time-resolved data. When you want to observe year-to-year variations, strengthen the basis for equipment comparisons, or check behavior at peak times, monthly values alone don't provide enough information. The greatest advantage of using time-resolved data is that it allows the temporal variations of solar radiation and temperature to be directly reflected in calculations.

However, because hourly data offer greater flexibility than monthly data, there are more precautions to take when importing them. The first thing to check is what each column in the file represents. If you load the file without first organizing which columns contain the date, time, solar irradiance, diffuse component, air temperature, wind speed, and how missing values are represented, it may appear to have been read successfully while its contents are actually compromised. In particular, data missing the main daytime solar radiation variables should not be used for analysis as is.

Next, the important point is the time reference. Observation data may mix standard time, daylight saving time, Coordinated Universal Time (UTC), or instrument-specific handling. If this is off, the radiation behavior in the morning and evening will appear unnatural, negatively affecting surface conversion and the estimation of scattering components. Beginners tend to look only at the solar irradiance values themselves, but in practice it is time consistency that determines quality. Even if the numbers look plausible, if the timestamps are off the calculation results can easily be distorted.

Also, you should check how many years of hourly data are available. Single-year data are strongly influenced by that year’s weather anomalies, so you need to assess their representativeness. If you have multiple consecutive years of data, it is practical to decide, depending on your objective, whether to treat a specific year as representative or to handle it as a multi-year comparison while checking each year’s characteristics. If a sufficiently long continuous record is available, it may be worth considering creating a representative-year dataset.

After importing, it is essential to verify the linkage with site information. Even if the time-series files themselves are correct, if the coordinates or elevation of the linked site are misaligned, interpretations of solar position and temperature conditions will differ. In practice, files are sometimes reused relying only on filenames and site names, which can lead to using data for the wrong location in a different project. To prevent this, it is important to explicitly document the correspondence between site information and meteorological data for each project and to avoid ambiguous file management.

Please translate the following input into English.

Consistency checks that must be performed after configuration

Meteorological data are less important for whether they were ingested than for whether they are correctly interpreted. Therefore, you should always perform a consistency check after configuration. The first things to check are the hourly and daily graphs to see whether seasonal and diurnal variations look natural. If basic patterns — such as higher radiation in summer and lower in winter, and the characteristic "mountain-shaped" change visible on clear days — are disrupted, there is a high likelihood of a configuration error somewhere.

Comparison with a clear-sky model is also useful. If solar radiation that clearly exceeds the clear-sky upper bound occurs frequently, you should suspect anomalous values, incorrect units, time offsets, or component mix-ups. Conversely, if values are too low all day even on clear-sky days, you need to consider whether surrounding shading has been incorporated, the sensor conditions are unusual, or the data actually come from a different location. The goal here is not to achieve a perfect match but to check whether the behavior is physically plausible.

The symmetry between morning and evening is also a significant clue. If the peak in solar radiation is unnaturally skewed toward the morning or the afternoon, a shift in the time reference may be hiding. Especially when hourly data are brought in from external sources, the position on the time axis is more important than the apparent numerical values. Because morning–evening imbalances are hard to notice when only looking at annual totals, it is important not to skip checking the graphs.

It's also effective to go back to monthly aggregates for verification. By checking whether the monthly trends recomputed from hourly data differ significantly from the original assumptions, you can more easily spot anomalies in data import or interpolation. Even if the annual totals match, if the month-by-month distribution is skewed, it becomes difficult to use for design decisions. In practice, some projects prioritize the summer peak while others focus on the low solar irradiance period in winter, so any inconsistency in the monthly allocation should not be overlooked.

Also, be sure not to forget checking for missing values. Even if the hourly files appear to be complete at first glance, just a gap during part of the daytime can make the results unstable. If missing data are few, clearly define a policy for imputation; if many, reconsider whether to use the data at all. If you press on simply because you can run the calculations, explaining the results later will become difficult. Reliable simulations start with not overlooking defects in the input.

Common Mistakes and How to Fix Them

The most common mistake is choosing weather data just because the place names are similar. Even within the same prefecture or the same municipality, conditions change due to differences in elevation and distance from the sea. The remedy is simple: check the coordinates and elevation rather than the name. Also, leaving a brief note in the project file about the reason for the selection will prevent confusion when reviewing it later.

The next most common case is confusing the roles of monthly data and hourly data. If you assume that entering monthly values makes the detailed analysis accurate, you'll misinterpret the results. Monthly data is a starting point, and the quality of the hourly data used in detailed calculations determines the final accuracy. As a countermeasure, explicitly state for each project whether the series you are currently using is an approximate series or a series based on actual measurements, and make that assumption clear in the documentation.

Time shifts are also troublesome. Even if annual power generation appears similar at first glance, inconsistencies accumulate in morning and evening irradiance, tilted-plane conversion, and the handling of diffuse components. The countermeasure is to check daily graphs and morning/evening distributions immediately after data ingestion. If there is a bias, it is easier to sort things out by suspecting, in order, the time reference, daylight saving time, and the time zone settings. Before chasing numbers, questioning the time axis is important when configuring meteorological data.

Double-counting of shading is also a common mistake among beginners. If the monthly values may already reflect the influence of terrain, applying additional shading conditions can lead to overestimating losses. Conversely, if you omit shading settings entirely because you are overly concerned about the influence of the observation site, you will end up ignoring the terrain of the planned site. As a remedy, rather than modifying the meteorological data itself, manage terrain conditions separately and, if necessary, compare separate cases.

Another often overlooked issue is the unknown origin of reused files. For example, you may reuse hourly files copied from past projects, but the original site or year can be ambiguous, making them impossible to explain. To prevent such incidents, at minimum record the file name, site name, coordinates, source, year, and whether any corrections were applied. Meteorological data setup is not a one-and-done task; you should consider it complete only when it is reproducible.

Tips for improving accuracy in practical operations

To increase the persuasiveness of results in practice, it is important not to pin yourself to a single dataset from the outset. In the estimation stage, grasp the overall picture using representative conditions based on monthly values, and in the detailed review shift to hourly data—this two-stage approach makes it easier to balance the speed and accuracy of analysis. Rather than aiming for maximum precision immediately, it is easier in practice to make judgments by sequentially checking how differences in assumptions affect the results.

When there are multiple candidate meteorological data sets, it's easier to make a judgment if you compare not only the annual values but also the monthly distribution, temperature trends, diurnal patterns (morning and evening shapes), and differences in site conditions. The important thing is not to hastily decide which data is absolutely correct, but to identify which assumptions are most easily explained in light of the project's objectives. Equipment comparisons, financial analyses, construction planning, and explanations of power generation performance each require different levels of granularity. Meteorological data settings should likewise be selected according to those purposes.

Also, understanding the planned site's terrain and the actual installation conditions early on makes the selection of meteorological data more stable. Even if a point looks nearby on paper, it is not uncommon that when you visit the site it turns out to be on the other side of a ridge, the slope aspect is different, or there are more obstructions than assumed. Meteorological data settings may seem like desk work, but in fact their accuracy improves through back-and-forth with on-site conditions. Trying to complete everything using only drawings tends to lead to more adjustments later.

Furthermore, in projects where annual data can be used, it is important to avoid treating the good or bad performance of a single year as a representative value. There will inevitably be years with unusually high solar radiation, years with unusually low solar radiation, or years with large temperature deviations. If you have hourly data spanning multiple years, compare single-year results with representative-year results to understand how wide the variation is; doing so increases your explanatory power. Especially in situations involving investment decisions or long-term financial performance, refraining from making definitive judgments based on only one year helps build trust.

Finally, keep in mind that meteorological data settings cannot be completed solely within the analysis software. In practice, the prior step is how to accurately determine the project site’s exact location, elevation, terrain, and surrounding conditions. If the coordinates used for input conditions are ambiguous, no matter how carefully you select meteorological data, the ceiling on accuracy will be low. For that reason, those responsible for simulations should be particularly attentive to how site information is obtained.

Summary

The basics of meteorological data setup are to define the location correctly, understand the separate roles of monthly and hourly data, and always verify consistency after importing. Even if it looks difficult, the points to check are clear: which location the data are for, what time reference is used, which physical quantities are included, and whether the seasonal and diurnal variations look natural. If you check in this order, even beginners can largely avoid major mistakes.

If you want to improve the accuracy of power generation simulations, it is essential not only to know how to operate the software but also to be aware of where the input conditions come from. In particular, with meteorological data, what matters is not whether it has been set, but whether you can explain it as an assumption. The larger the project, the greater that accountability becomes. For that reason, meteorological data settings should be handled carefully, not as mere initial tasks, but as a foundational process that supports the quality of the analysis.

And what further strengthens this foundational process is the accuracy of on-site information. If you can quickly grasp the exact position and elevation of the planned site and the surrounding terrain conditions, selecting meteorological data and organizing shading/obstruction conditions becomes much easier. If you want to connect site inspection, design, and reporting seamlessly, using an iPhone-mounted high-precision GNSS positioning device such as LRTK is also an effective method. By obtaining high-precision positions on site and recording them together with photos and point clouds, you can more easily reduce discrepancies between desk-based simulation conditions and the actual field situation. From the perspective of turning meteorological data settings into reliable practice, improving on-site positioning accuracy is a powerful asset.