André Mermoud

Sorry, this dialog is not always optimal for some complex projects. We are working on the improvement (and refinement) of this possibility, for a next version. But I don't know when this will be available.

In version 6.22, there was an error in the simulation when you are using the "Mixed orientations" on a same inverter, which had the effect of diminishing the Inverter losses. This error has been corrected in the version 6.23. A loss of 0.4% only for the inverter efficiency is indeed not realistic.

We just did this modification as simultaneous running is the cause of many reported crashes of the program. Now there are some files which are permanently used by PVsyst, not only the project's files. We will perhaps try to secure the simultaneous running of multiple instances of PVsyst in a future version.

The lifetime of the batteries is split into two contributions: - a "static" ageing (specified in the battery's component definition). For lead-acid batteries, this is very dependent on the battery temperature: an increase of the temperature results in halving the lifetime. - an ageing according to the number of cycles: this is continuously calculated by the detailed simulation process. The wearing state is a result of the simulation. The economic evaluation doesn't take a controller lifetime into account. The economic evaluation of Stand-alone systems evaluates the maintenance cost as the fourth of the battery price (i.e. a lifetime of 4 years), without any other contribution. This is a very simplified assumption. However in the presizing part, please take these costs with great care: it is quite impossible to give a serious information about the prices in the framework of such simplified simulation and assumptions. The costs are depending on many factors, and specific to each situation (country, time, etc).

This depends on the technology. With crystalline modules, this is the LID (Light Induced Degradation) and may be specified as such in the "Detailed losees" dialog. This loss arises usually during the first hours or days of exposition to the sum. With amorphous, the initial degradation (some months) is not taken into account in the simulation: the STC specified values are supposed to be the stabilized values.

A better accuracy in the monthly values of temperature is not really meaningfull. These Monthly values are not used as such in the simulation. They are the basis for a synthetic generation of hourly values. This process is completely random: with 2 different executions you can have completely different sequences of days and hours within the month. Therefore you will never be able to strictly compare simulations for a same system based on different synthetic meteo data files.

No, because there is no optimum: this is a multi-criteria and multi-variable problem. See for example the article Optimization of row-arrangement in PV Systems, shading loss evaluations according to module positioning and connexions (A. Mermoud, EPVSEC 2012), on our site.

Thank you for the detailed report of the problem. Sorry, the logics for forbidding modifications of the PV module definition was inverted. This is corrected for the next version 6.23.

Thank you for noticing this. I have corrected for the next version 6.23.

I can't understand that. Please check (at the top of the column) that the values are not expressed in W instead of kW. If the problem persists, please send your whole project to Support@pvsyst.com.

This is indeed on our ToDo list since a long time... We will provide the opportunity of producing comma decimal characters when exporting CSV and Copy/Paste operations in a next version very soon (not necessarily the next one).

In the System part, you have defined modules which will require a given area. In the 3D shading part, the area foreseen for this sub-array has not sufficiently area for placing all the PV modules defined in the system. Therefore there is a contradiction in you system design.

Yes, in the 3D definition, when defining "Sheds" fields, you have the parameter "Baseline slope". Please see also our FAQ With sheds on a tilted roof, PVsyst changes my orientation

This is a very difficult question, which strongly depends on the input meteo data, and simulation parameters. Validation of the model To evaluate the accuracy of the simulation, the simulation results should be compared to measured data. The difficulty lies in obtaining high quality measured data for this assessment. The data recorded on existing plants are usually proprietary, and we have no access to them. The accuracy evaluation is made of 2 components: the measurement accuracy and the modelling accuracy : Measurement accuracy: irradiance measurements are not easy to perform, and require very well calibrated instruments, which is rarely the case. The measurements of electrical data are usually more accurate. However misfunctions of the system are often not well documented, and may significantly affect the results which are then compared to the simulation output. This is especially the case when the comparisons are performed on accumulated data (not in hourly values). Modelling accuracy: With given meteorological data, the main uncertainty is probably the PV module's performance, which is based on - STC values provided by the manufacturer and temperature coefficients. - The additional parameters Rshunt and Rserie, which may be either default values or established according to Low-light irradiance performance data (measured on 1-2 modules - representative ?) - Deviation of the performance of the installed modules with respect to these specifications: is the tolerance respected ? What is the LID or PID or degradation effect ? The shadings are evaluated by complex models, however their impact on the performance are usually less than 5 to 10%, so that inaccuracies should be less than 1-2%. Other losses are specified by user defined parameters (wiring loss, inverter behavior, other components, soiling, unavailability), and may be set at any value, therefore not really significant to the accuracy of the simulation process. Simulations for yield forecast When using the simulation for predicting the yield of an installation, the main uncertainties are: - The input meteorological data: nobody knows the wheather for the coming years, and there is some discrepancy between the available historical climatic data (see "Meteo Data Comparisons" on the PVsyst site) - The real PV module's behaviour with respect to the specified parameters; and the PV module temperature (depending on the mounting mode and possibly the wind speed). - The operating conditions (soiling, unavailability, etc). NB: If you have to present yield warrantiess to a customer, you are advised to get rid of the meteo variability (and unprevisibility), by proposing a yield related to the effective irradiation during operation. This will require to foresee a reference Meteo data source (own measurements or satellite) in your contract, for the renormalization of the real yield with respect to the original simulation. The renormalization is rather easy, since for grid connected systems, the yield can be assumed to be proportional to the input irradiation. According to our own experimental results, we estimate that the simulation process itself has an accuracy of the order of 1 to 2% for the yearly yield. You can see for example our analyzis of an installation of amorphous modules, but sorry, only available in French.

Yes, you can read the array temperature when importing a custom meteo file. The temperatures should of course be present as an hourly data column on the ASCII file. And you can of course use it during the simulation, to be chosen in the panel "Detailed Losses" / "Thermal parameters".

I have just discovered and corrected the fact that the "System" button is red after reading a file with SolarEdge architecture. This will be corrected in the next version 6.23.

The limit on the Ratio "Pitch / Tracker width" is indeed 1.05 (not in the hidden parameters - sorry) This is a very low limit. Tracking systems with such low pitch don't make sense. However this limit was established for backtracking, and should not be applied to "normal" tracking systems. This will be corrected in the next version 6.23.

Please check that the Diffuse part is correctly defined in your meteo data. This effect in the transposition is very probably related to an underestimated (or even null) diffuse part.

Please check that the Diffuse part is correctly defined in your meteo data. This effect in the transposition is very probably related to an underestimated (or even null) diffuse part.

You are working with the version 5. You can uncheck the checkboxes representing the 2 undesired files. This is more simple in the version 6: you define only one sub-array with "Mixed" orientation.

You can use the tool "Batch mode", to be defined just before performing the simulation. This tool allows to perform several simulation at a time, by varying different parameters, and get the results on an EXCEL file.

The correct definition of the time stamp in imported data is a very important issue when importing external data. It is explained in detail in the Help: Meteorological data > Hourly meteorological data > Hourly meteo data quality check Meteorological data > Hourly meteorological data > Time shift The time stamp beginning or end specification is defined in the importing format of the "Import ASCII meteo files" option.

Some answers to your questions • Assuming that the “fans and auxiliary” value is power over and above that characterized in the power threshold value….? The loss is indeed accumulated at each time step, as soon as the instantaneous power delivered by the inverter exceeds the "Power threshold". • Are these losses subtracted from EOutInv, or maybe EArray? They are substracted from EOutInv, as shown on the array loss diagram. • Is the “Fans and auxiliary” value subtracted during hours of operation (once the power threshold is exceeded)? Yes, Is “Night consumption” subtracted during the other hours? It is substracted when the inverter's output is 0. • We don’t understand the “... from output power” field. What happens if this isn’t set to the power threshold value found under the main parameter tab? This field has nothing to do with the "Power thhreshold" of the main parameters, which is the minimum array power at which the inverter begins to produce.

This arises sometimes, and we still don't understand well why. This is usually due to the fact that you have defined big fonts in your Windows installation. Please try to choose little ones. You can do that in the "Control panel" / "Display", or on the Windows desktop, right-click and choose "Personnalize" or "Preferences", "Display". Now sometimes you already have little fonts selected: choosing medium ones may solve the problem. However in some very rare cases, this doesn't work. In this case please contact support@pvsyst.com.

For this example, please send me the whole project in order that I can analyze the situation (using "Files" / "Export whole projects" in the main menu). You can send it to support@pvsyst.com. For the second question: I don't think the simulation behaves as you describe. During the hour of simulation, the battery voltage is evolving according to the energy balance. If a regulator threshold is met (regulator switching), then the part of hour is accumulated as such, and the simulation begins again from this instant according to the new regulation state. This is only possible once in the hour; however it is probably sufficient if the thresholds have been defined correctly (i.e. if the hysteresis is sufficient).