André Mermoud

The synthetic generation is a statistical model, based on the real measured data of dozens of sites. The elaboration of such a model is very complex, and it required very sophisticated checks. It is not possible to modify it, by addin such "fuzzy" conditions. The only way for your evaluation is to use really measured hourly values.

In the DC part: you should check the "Default" checkbox. And if the default value doesn't meet your requirements, you can modify it in the "Hidden parameters", "System design parameters", item "Default wiring resistance loss ratio". For the AC part, there is no default and I don't see how to specify a stable loss whatever the power in the present state.

This is indeed a very special case, probably the only one implying a random parameter. We have to allow some new parameters to be varied in the batch mode. We will think about that.

I don't understand your affirmation. It is quite possible to define a tracking system with axis tilt = -1° or +1°, event in the 3D tool. There is no restriction here. I know that architects are often using percentages for the tilt. They also use to take the North as azimuth reference. However in most solar applications this is expressed in terms of degrees. It would be very confusing to work in two different units for a such fundamental parameter in PVsyst.

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.