PVSyst Storage Locations and Data Management｜5 Practical Tips for Practitioners

Table of Contents

• Understanding where PVSyst saves files is the first step in practical management

• Types of data that should be managed in PVSyst and their roles

• Tip 1: Separate folders by project and standardize the save location

• Tip 2: Decide rules for file naming and version control from the start

• Tip 3: Store meteorological data, equipment data, and simulation results separately

• Tip 4: Separate working data and submission data when sharing

• Tip 5: Improve reproducibility by linking backups with on-site data

• Common mistakes in managing PVSyst storage locations and how to avoid them

• Strengthening power generation assessments using PVSyst with on-site data

• Conclusion: Organizing storage locations is a practical skill that supports simulation quality

Understanding where PVSyst stores files is the first step in operational management

When using PVSyst in practice, the first thing to understand is that simulation results are not confined to what appears on the screen. Project conditions, site information, meteorological data, equipment specifications, shading settings, loss conditions, calculation results, output reports, and various other data all interrelate to form a single analysis outcome. Even if a project can be opened on the screen, multiple files and reference datasets are stored behind the scenes in the storage location, and if they are not properly managed it becomes difficult to recalculate or compare results later.

What you should be particularly aware of regarding PVSyst's storage location is which workspace you are currently using. In photovoltaic simulation software there is a workspace that centrally manages project data, and project-related information and reference data are stored within it. What practitioners should first check is which storage location the project they currently have open belongs to: the company's shared folder, their own working folder, or a temporary folder copied from past projects.

If you proceed with work while leaving the storage location ambiguous, you may later end up with multiple projects with similar names and not know which one is the latest. For example, as stages multiply—initial study, revised version, submission version, internal review version, re-estimate version—just having unorganized storage locations and naming rules can make verification time-consuming. Furthermore, when another person takes over the same project, if the explanation of where files are stored is insufficient, they will spend more time searching for files than confirming simulation conditions.

To master the practical use of PVSyst at a professional level, it is important not only to learn the operation procedures but also to understand the flow of data, including where it is stored. By organizing which data to input, which data to reference, and which results to retain, you can respond calmly if conditions change later. Understanding the storage locations is the foundation for preserving the reproducibility of simulations.

Types of Data to Be Managed in PVSyst and Their Roles

The data handled by PVSyst is not just a single project file. In practice, it is easier to manage if you separate it into input data, reference data, calculation conditions, output data, and explanatory materials. If you store all of these haphazardly in the same location, it becomes difficult to tell later what is the source data, what is work-in-progress data, and what is the final data for submission.

The input data include the plant location, installed capacity, module layout, tilt angle, azimuth angle, shading objects, and loss conditions. Because these directly affect the simulation results, it is necessary to keep a change history. In particular, tilt and azimuth angles, series-parallel configuration, combinations of equipment, and site conditions can cause differences in annual energy production and loss assessments with even small changes. Therefore, it is important to keep records so that it is clear when, who, and which conditions were changed.

Reference data include meteorological data, terrain data, equipment data, on-site survey data, and information related to shading. Because these serve as the assumptions for simulations, they are as important as project data. For example, if meteorological data are replaced, the calculation results will change even under the same equipment conditions. Updating local terrain or obstacle information also affects shading evaluation and layout considerations. If you work without organizing reference data, you may later be unable to explain "which data were used for the calculations."

Output data includes calculation results, reports, comparison materials, documents for internal review, and documents for submission. Because output data is often shared with stakeholders, it is necessary to clearly separate work-in-progress results from the final version for submission. In particular, in projects where conditions have been changed repeatedly, there is a risk of accidentally submitting old results that remain. In practice, it is important not only to save output data but also to keep it in a state that allows tracing which input conditions produced those results.

What matters in data management is not classifying everything in detail, but creating a structure that won't lead to confusion later. If you design storage locations so that, according to the scale of the project and internal rules, the flow of input, reference, work, submission, and storage is naturally clear, PVSyst operation will be considerably more stable.

Tip 1: Create a separate folder for each project and set a fixed save location

In practice, the first thing you should do is separate storage locations by project. Before creating a PVSyst project, first create a basic folder for each project and consolidate related data within it; this makes it easier to find later. Combine the project name, location, the month and year of the study, internal reference number, and other identifiers to create a name that lets anyone identify the project.

Fixing the storage destination means not moving data around during work. Use the project folder decided at the start of the task as the reference, and manage the input data, reference data, and output data related to that project within the same structure. If you temporarily copy files to another location to work on them, it can become unclear which one is correct. This is especially true when multiple people are working: if each person keeps a separate latest version on their own device, it causes confusion during review.

In a project folder, separating work-in-progress data from submission data makes practical work easier. Work-in-progress data includes estimates, comparisons, changes to conditions, and interim results under review. Meanwhile, submission data stores internally approved results and materials used for client presentations. Creating this separation reduces the risk of accidentally sharing unverified work-in-progress data.

Also, it is important to organize not only the PVSyst project save location but also the storage locations of the source data used in that project according to the same principles. If meteorological data were loaded from another location, terrain data were received from external sources, or on-site survey data were added later, having scattered reference sources reduces reproducibility. If possible, keep copies of the data used in the project inside the project folder so the same conditions can be reproduced later.

Simply fixing the storage location for each project makes using PVSyst considerably more practical. While getting used to the interface is important, when data is organized by project, requests for corrections, condition comparisons, internal reviews, and handovers all proceed smoothly.

Tip 2: Decide the rules for file names and version control up front

File naming and version control are common pitfalls in PVSyst data management. A typical example is the proliferation of names such as latest, latest2, revised, final, and final revision, which makes it unclear which file is truly the most recent. While you can somehow remember when working alone, confusion quickly arises when you revisit the files a few weeks later or when a different team member checks them.

In practice, including the project name, analysis conditions, date, and version number in file names makes them easier to manage. For example, inserting a short identifier for the project, an outline of layout conditions, the classification of simulation conditions, the creation date, and the version number in a consistent order makes it easier to compare files when they are displayed in a list. The important thing is not to name files on the spur of the moment each time, but to follow the same rules company-wide or among the people responsible.

In version management, it's important to clearly separate working versions from approved versions. Working versions are updated repeatedly because they include condition changes under consideration. In contrast, approved versions are used for internal review and submission, so it's safer not to overwrite them indiscriminately. If you perform additional review after preserving the approved results, save them as a separate version. This allows you to distinguish later between the "submitted results" and the "results of additional review".

When you change conditions, leaving a brief change note in addition to the filename will be even more useful in practice. For example, recording information such as that you changed the tilt angle, swapped the meteorological data, revised the loss conditions, added objects that cast shadows, or adjusted equipment capacity will make it easier to explain later why the results differ. In simulations, numerical results tend to attract attention, but it is important to record the assumptions under which those numbers were produced.

The basics of version control are to keep past results and to make clear which version was created for what purpose. If you operate by only overwriting, you may lose the ability to compare with the previous conditions. Especially in situations such as internal reviews or customer explanations where you are asked, "What has changed since last time?", whether version control is being properly implemented directly affects the quality of your responses.

Tip 3: Store weather data, equipment data, and simulation results separately

When managing storage locations in PVSyst, it is important not to put all data into a single folder but to store them separately according to the nature of the data. In particular, meteorological data, equipment data, and simulation results each have different roles. If these are mixed together, it becomes difficult to tell which data are input conditions and which are output results.

Meteorological data are important information that form the basis for power generation simulations. Even with the same equipment conditions, the choice of meteorological data can change the annual energy yield and monthly trends. Therefore, it is advisable to clearly store, for each project, which meteorological data were used, when they were obtained, which location they correspond to, and whether any processing or corrections were applied. This also makes it easier to explain differences from the original conditions if the project is later re-evaluated under different meteorological conditions.

Equipment data must also be handled carefully. The specifications of solar panels and power conversion equipment have a major impact on the assumptions of simulations. When information such as model, ratings, temperature characteristics, and efficiency characteristics changes, the calculation results will also differ. In practice, because equipment candidates are often compared, it is important to record which equipment data were used for the calculations. If candidates are changed, store the old and new conditions separately so they are not confused.

Simulation results should be organized separately from input data and reference data. Because result files and output reports often serve as materials for stakeholders to review, it is easier to manage them if they are saved by condition, date, and version. In particular, when comparing multiple scenarios, including information in the result name that indicates the differing conditions makes the intent of the comparison easier to understand later.

The purpose of storing data separately is not just to keep things neatly organized. It is to provide accountability for simulation results. In practice, you need to be able to explain not only the power generation figures but also which meteorological conditions, which equipment conditions, and which layout conditions those figures were derived from. If you organize where you save them, you won't spend time checking conditions and can concentrate on the actual design decisions.

Tip 4: When sharing, separate working data and submission data

When sharing PVSyst data internally or externally, it is important to separate working data from submission data. Working data may include conditions under consideration, provisional calculation results, unverified settings, and temporary comparison data. Sharing these as-is may cause recipients to mistake them for the final results.

Submitted data should, as a rule, summarize only the results based on confirmed conditions. Clearly separate items that have passed internal review, those intended for client presentations, and those retained as records, and store them in locations separate from in-progress data. In the submission folder, organize and include the necessary results, explanatory materials, a summary of conditions, and output reports, and exclude any unnecessary provisional calculation data. This enables recipients to review the materials without confusion.

One thing to watch out for when sharing is that simply handing over the PVSyst project data may not allow the recipient to reproduce the same state. If the meteorological data, equipment data, terrain data, or shading information it references are stored elsewhere, the recipient’s environment may be missing them. Therefore, before sharing you should verify that all data required for reproduction are included. In practice, it’s safer to organize and provide not only the project files themselves but also the reference data and notes on the conditions used.

When sharing internally, it is also important to separate data that may be edited from data that is view-only. If multiple people edit the same data directly, unintended overwrites or changes to conditions can occur. When the person in charge is clearly defined, restricting edit permissions for working data and having reviewers view the submission data can reduce confusion. In collaborative work, it is also important to keep a record of who updated which version.

When submitting to external parties, do not hand over the entire work process; instead, organize and provide only the scope necessary for explanation. In addition to the calculation results, include materials that make the main assumptions clear so that recipients can more easily understand the results. The more you are sharing with stakeholders who are not familiar with how to use PVSyst, the more necessary it is to make the storage locations and file structure easy to understand.

Tip 5: Improve reproducibility by linking backups and field data

The final, indispensable aspects of PVSyst data management are backups and linking to on-site data. A simulation is not created once and then finished; it may be reviewed many times due to changes in conditions, design changes, equipment changes, and revisions after on-site verification. Therefore, having backups that can restore past states provides much greater assurance in practice.

It is not enough for backups to simply duplicate the same data. You need to make clear when the backup was taken, which version it is, and for what purpose it was saved. For projects with daily work, it is effective to keep backups at important milestones. Storing backups at times when you might want to revert—such as upon completion of initial study, before submitting for internal review, before client submission, before changing conditions, and at final save—makes it easier to respond when problems occur.

Linking with on-site data is also important. In PVSyst simulations, not only desk-based settings but also the site's topography, surrounding obstacles, orientation, tilt, available installation area, and shading factors affect the results. Organize photos, positioning data, terrain data, notes, and other materials acquired during the site survey within the project folder, and record which simulation conditions they were applied to; this will increase the reliability of the results.

If on-site data is not organized, it becomes difficult to verify the rationale when revisiting shadow settings and layout conditions later. For example, if you reflected obstacles confirmed on site in the shadow settings, and there is no record of how you determined those obstacles’ positions and heights, it will be hard to explain during a review. Conversely, if the on-site data is linked to the PVSyst settings, you can specifically explain why those conditions were chosen.

Linking backups with on-site data is a mechanism for enhancing the reproducibility of simulations. Because it demonstrates that analyses took actual site conditions into account, it not only calculates power generation but also strengthens credibility in internal and customer presentations.

Common mistakes in managing PVSyst save locations and how to prevent them

One common mistake in managing PVSyst save locations is to start working with the default settings and then not know where the data are being saved. If you don’t check the save destination before you begin work, it can take a long time to locate project data later. This is especially important when you use multiple working areas or create a new project by copying a past project.

Another mistake is that when reusing a past project, old conditions can remain. In solar PV simulations, you may duplicate a similar project to work on, but unless you review everything—location, weather data, equipment parameters, shading settings, loss assumptions, and so on—conditions from the previous project can become mixed in. Even if you store files separately, neglecting to verify the settings can lead to incorrect results. When reusing a project, make the relationship between the original and the new project clear and record which items were changed.

Accidentally overwriting files intended for submission is a common issue. If you save something as the final version and then make additional edits and overwrite it, the conditions at the time of submission can be lost. It is safer to keep submitted data as an archive and carry out further revisions in a separate version. In practice, since there are often occasions to review submitted data later, it is important to preserve the state of past submissions.

Another easily overlooked mistake is failing to save reference data. Even if the project data remains, the meteorological data or on-site data you loaded may be stored elsewhere and later become unfindable. To prevent this, consolidate and store the reference data used for the project within the project folder, and avoid deleting original data received from external sources.

Finally, it is also important not to make management methods that only the person in charge can understand. Even storage locations or names that make sense to you may not convey meaning to another person. In practice, it is essential to organize things in a way that anyone can understand. Organize using the project name, date, version number, and condition name, and leave a brief explanatory note when necessary to make handovers and reviews easier.

Strengthening Energy Yield Assessments with PVSyst Using On-site Data

The purpose of organizing PVSyst storage locations and data management is not simply to arrange files neatly. Ultimately, it is to improve the accuracy and explanatory power of power generation assessments. In solar power system design, not only meteorological and equipment conditions but also site terrain, orientation, tilt, shading, and the available installation area are important. By correctly obtaining these on-site details and linking them to the study conditions in PVSyst, you can reduce the discrepancy between desk-based analyses and actual field conditions.

When handling on-site data, positioning accuracy is important. If site boundaries, the locations of obstacles, terrain variations, and reference points for panel placement remain ambiguous, uncertainty will also persist in simulation layouts and shadow assessments. In particular, for projects on sloping land or with nearby structures, acquiring on-site location information as accurately as possible and managing that data within the project folder becomes an operational advantage.

Useful in this context are iPhone-mounted GNSS high-precision positioning devices such as LRTK. By organizing the high-precision positional information, point clouds, and photographic records acquired on site as project data, and using them for layout studies in PVSyst, shadow checks, and to substantiate design conditions, you can enhance the explanatory power of simulation results. If you organize storage locations and manage PVSyst project data and on-site surveying data per project, it will also be easier to trace the basis when reviewing conditions later.

If you want to deepen your practical use of PVSyst, it’s important to consider not only operating the software but also how to acquire on-site data, how to store it, and how to incorporate it into simulation conditions. Rather than just producing power generation figures, being able to demonstrate that those figures are based on actual site conditions greatly increases the reliability of design studies.

Summary: Organizing storage locations is a practical skill that supports simulation quality

The storage location and data management for PVSyst are aspects that beginners often overlook but are critically important in practice. By organizing where to save projects, which weather data to use, under which equipment conditions to perform calculations, and which version to use for submission, you can improve the reproducibility and explanatory power of simulation results.

The basics that are useful in practice are to fix the storage location for each project, establish rules for file names and version control, and store meteorological data, equipment data, and result data separately. Additionally, when sharing, separate working data from submission data and keep backups at important milestones so that later review and corrections are easier. These tasks are not particularly difficult, but if you don't establish rules at the outset, it becomes difficult to organize things later.

When learning how to use PVSyst, it's important to master not only screen operations and calculation settings but also the principles of data management. If save locations are well organized, changes to conditions, comparative analyses, internal reviews, customer explanations, and handovers will all proceed smoothly. Conversely, if save locations remain unclear, no matter how carefully you run simulations you will be unable to verify the supporting evidence later, and the reliability of the results will be weakened.

Connecting desk-based assumptions with on-site realities is increasingly important when evaluating solar power generation. By organizing PVSyst simulation data on a per-project basis and linking it with the high-precision on-site positioning data, point clouds, and photographic records obtained with LRTK, you can clarify the basis for energy-yield assessments. Organizing storage locations is not merely file management but the foundation for conducting reliable, field-based design studies.