André Mermoud

The TMY2 and TMY3 formats are very specific and well-defined formats (see http://www.nrel.gov/docs/fy08osti/43156.pdf). PVsyst has established the import of files corresponding exactly to this format, and this works quite well with the files provided by the NREL. But it is not guaranteed for other sources. Now we have proposed a "PVsyst format" for the meteo data several years ago (see a description in the help). 3-Tiers has agreed to propose their data in this format when requested. Please ask them. By the way you can probably import your data using the general tool "Databases > Import meteo ASCII files" (and Press F1 for getting the procedure).

Your comparison with a window is correct for a vertical plane. However the additional yield of the albedo goes with (1-cos(tilt)). If this is 100 % for a vertical plane, it is only (1 - cos(30)) = 13.4% for a 30° plane, and 6% for a 20° tilted plane.

I don't understand what you mean. The tiles cannot bring any albedo contribution to the PV modules here, as the PV module doesn't "see" them. In a general way, the albedo is proportionnal to the cosinus of the corresponding incidence angle. Therefore any radiation coming from a surface in the plane of the array will have a null contribution. On the other hand, the electrical yield of a string of modules is lead by the poorest module (the less irradiated). Therefore for being really efficient, a reflexion should be homogeneous on a whole module string.

Yes, this is the way of running of the PVsyst simulation, and probably of most inverters. I don't see what could be the meaning of the Vmppmin specification if this were not the case. If you choose "Cut" instead of "Limitation" for the behavior at VmppMin/Max, the inverter will stop.

The site, country, region and used Meteo data are already mentioned in the header of the output CSV file. With the files used and dates, the simulation header and date, these informations completely define the project's properties and simulation conditions. We could of course put any other parameter. I don't see why the Latitude and not the plane orientation, installed power or other.

This terrain description tool is a very new feature. We have still to refine some procedures with it. We will namely think about this problem. In the next version 6.35, to be released very soon, when watching the scene in Plane view you will have the information of the altitude of the terrain, making easy to position your object. The automatic positioning of all kinds of objects will be for a later version.

The discrepancy between Simulated and Measured data may be due to: - An error in the measurements, - A misrunning of the system, - An error in the simulation program - An error in the design parameters used in this simulation, - An error in the input meteo data (either measurement or importing in PVsyst). Nobody can anwer your question without more information. You have to check all these possibilities. The better way is to analyze hourly data discrepancies. However PVsyst is used by tausends of people. I don't think that a simulation error is very probable...

The OND files generated by versions superior to V6.26 are indeed not readable with previous versions. This is a problem without direct solution. But it is anavoidable when some new information has to be added in the file. You should ask SMA for creating an OND file with a version < 6.26. For the next version 6.35, I'm preparing the opportunity of creating files compatible with old versions. But this will not solve your problem.

In principle files of V5 should be readable in V6. Perhaps there is another problem (for example a missing file). Please ask your client to use "Files > Export project" in the main menu for ensuring that all the required files are present. When installing the V5 on your computer for the first time, you can use the program during 15 days. If you really need the V5, you can ask for a temporary license code to our administration.

We discovered indeed an error in the simulation of systems with Mixed Orientations in the versions 6.33 and 6.34. This will be corrected in the next version 6.35, to be released very soon.

The "Overload loss" is the not-produced energy, sum of the differences between the available Pmpp and the effective limited power accepted by the inverter according to Pnom when limited. This value is computed at each simulation time step. It is not proportional to the power ratio of course, as it is a non-linear effect: when diminishing the Array power, only a few days/hours will be affected by this threshold variation. Please see the histogram in the tool "Show optimization" (System design dialog), and play with the power ratio for understanding the phenomenon.

We discovered indeed an error in the simulation of systems with Mixed Orientations in the versions 6.33 and 6.34. This will be corrected in the next version 6.35, to be released very soon.

If you specify Uv = 0, the wind velocity will not be implied in the simulation, whatever your choice for the Uc value. You can consider that when putting Uv = 0, the wind effect should be included (as a constant average value) in the U value.

I don't understand well what you are doing. Please take your project. Run the simulation with one meteo data file (for example what you call "My monthly meteo is 101.5 kWh", but don't define frome where it is taken). Then just change the input meteo data file in your project (for example meteonorm). Run it again without changing anything. The resulting yield should be fairly proportionnal to the input irradiance. Now if there are big discrepancies these may be due to a very bad hourly meteo file (for example a time shift). Please carefully check your meteo file using "Databases > Meteo tables and graphs > Check data quality", and here press F1 for detailed explanations.

If you have 2 modules in portrait in the width of you shed, the shed's width is indeed 2 x length of one module (plus the spacing between them).

Reading formats of specific data (like SolarGIS) follows usually very "rigid" rules. And a half-hour time zone is perhaps not recognized. Or perhaps the SolarGIS file format has been changed. Please send us this SolarGIS file (to support@pvsyst.com).

As you mentioned, the battery bank estimation in PVsyst is expressed as C10 value, as the "characteristic capacity" specifying the batteries in PVsyst is C10. However these sizing results should only be interpreted as a rough estimation. There is no absolute way of defining the size of a battery bank, as this depends mainly on the meteo variability, and the eventual unequal use of the electricity. In PVsyst, the estimation is performed by: - generating a synthetic daily data set from the Monthly meteo data. - performing a quick (simplified) simulation during this full year. - estimating the probability of "loss of load" (PLOL, user's disrupting time), and adjusting the battery bank according to your specification. Now this process is mainly dependent on the worst days sequence in the meteo data, which is highly variable, and depends on the synthetic generation. In a next version of PVsyst we will provide a tool for performing a large set of Synthetic generations and analyze the probability distribution.

Yes of course. It is quite impossible to compare the instantaneous values with measured ones when you have meteo data specified in monthly values, which is the case for Meteonorm, PVGIS and NASA. With such monthly data, the Daily and Hourly meteo data are randomly generated (synthetic hourly data generator), and cannot correspond to any real instantaneous data. The only way for analyzing measured data of a power plant is to measure the Meteo (irradiance and temperature) on the site (or very eventually to get simultaneous measurements from a nearby station, or Satellite with a very narrow resolution). And even the Monthly values cannot be compared accurately, as the data of the Historical sources are usually averages over several years, which cannot correspond to the weather of your particular month.

We discovered indeed simulation errors in the V 6.33 and 6.34 when using Mixed orientations. These will be corrected in the next version 6.35.

There is no direct mean of sizing the sheds configuration, as this is a multi-variable (and complex) problem. However you have a pedagogic tool for the understanding of the basis of the shed optimization. In the "Orientation" part, please choose "Unlimited sheds". And here you have a button "show optimization" which shows the issues. You can press F1 for explanations in the help.

This is not possible with the simplified "Unlimited sheds" option. You should do that by defining a 3D representation of your system.

No, this is not possible, sorry. The simulation report is the reference. The parameters displayed are those which may be modified fom one run to another one.

The problem is here in the inverter's definitions. Please carefully check these definitions, namely for the nominal power and the operating voltage. Please have a look on our FAQ Why sometimes the overload losses increase without reason ? You can directly analyze the evolution of the different variables in hourly values, using "Hourly Graphs" in the Results dialog. NB: I see that you have drawn this "Loss diagram" for a very short time (probably one only day). This may explain that the losses have not the same magnitude than on usual yearly simulations (for example for the temperature loss).

The basic language of PVsyst is English. Some parts of the software - and namely all the reports to be distributed to your customers - are available in other European languages. We are on the way for completing the translation of other parts of the software itself (namely the stand-alone and pumping systems). However the help remains in English, as well as the tutorial. Sorry, we didn't translate these documents up to now. It is rather difficult, as they are often subject to be changed and improved; updating a documentation in several languages is really a hard challenge.

It is rather simple: - In the "Orientation" part, you define the 2 orientations and the relevant months for summer and winter positions. - In the "System" part, you define your system as usually. - In the 3D shadings, you define a system with fixed orientation (either sheds or rectangular fields), corresponding to the summer orientation. You will see that the shading tables - and iso-shading diagram - will be constructed for both orientations. And the simulation will take this configuration into account according to your specifications (you will observe an increased gain for the "Global incident", with respect to summer orientation)).