André Mermoud

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).

You can simply download the version 5.73 from www.pvsyst.com, and install it over your existing PVsyst. You will find this version 5.73 at the bottom of the PVsyst downloading page.

The estimation of the Battery capacity is a rough calculation of course. It is computed with very uncertain parameters, like the admitted DOD, or the ratio of the C100/C10 capacity definition, or even the capacity specification itsef ! Now for taking the efficiency into account, you are partially right. The capacity is indeed related to the State of Charge (or vice-versa). Now when charging, you have a loss due to the internal resistance, and also the gassing at high SOC. When discharging, you have a loss due to the internal resistance. Both are strongly related to the instantaneous charging or discharging current. For the required capacity evaluation, we should indeed take the discharging losses into account.

The losses are computed using a fixed resistivity, corresponding to a temperature of 50°C (see the help "Glossary > Metal resistivity"). By default, it is supposed to be copper (i.e. 22 mOhm·mm²/m). For the array, this value may be modified in "Detailed Losses" / "Ohmic losses" / "Detailed computation" / "Wires". For the AC losses, the resîstivity is taken for copper, as specified in the Hidden parameters, topic "System design parameters", item "Copper resistivity". The losses displayed in the dialog are computed for STC conditions. But the loss is accumulated at each simulation hour according to the real current of course. The current is taken according to the real power as managed during the simulation, it doesn't change with a different CosPhi.

I don't know this problem. Please send us the concerned MET file (to support@pvsyst.com)

This was an accidental error in the version 5.72, when reading the file. Please update to the version 5.73. Perhaps you will have to redefine correctly the Phi limit if the file was written by the version 5.72.

The wearing state has two parts: - a constant wearing according to the time and the battery temperature: the static lifetime diminishes by a factor of 2 for an increase of 10°C, - a wearing due to the use of the battery, i.e. the number of charge/discharge (according to the specification in the battery's parameters). The simulation calculates the wearing state at each simulation step, according to the IN/OUT current and the instantaneous depth of discharge. You can find it in the simulation results. For example in the monthly results, table "Battery operation and performance", variables WECycle and WEState

This error has been corrected since a long time. Please update to the latest version.

Yes of course. You can read files of the version 5 with the version 6, but not the inverse (upwards compatibility).

No, you cannot define explicitely a PID loss in the present time. You can define a LID loss. For other losses related to the PV moudles, you can use the parameter "Module quality loss".

Hi Shy There were indeed an error in the simulation when using the "Module Layout" option, up to the version 6.19, affecting the inverter efficiency (in fact the EArray value). - Does this strange result still occur if you update to the latest version ? If yes, please send me your whole project. Yes, the Il_VmppMin may result of voltage drop due to shadings in the Module Layout part.