André Mermoud

This is quite normal. If you have overpower conditions, all the production hours for which the Power is limited will fall in this last bin (corresponding to PNom).

You cannot mix different PV modules in a single sub-array. The only way to do that is to redefine your inverter as a Multi-MPPT inverter, and attribute different sub-arrays to different MPPT inputs.

By which amount ? The shading calculation principles are very different between the 3D and the Unlimited sheds models. However if you correctly define the 3D scene (i.e. by observing the hypothesis of the "unlimited sheds", i.e. very long sheds or rows), both simulations usually give close values. Now the optimum tilt angles have a very broad maximum: large interval in tilt may lead to very little yield differences. So that the maximum tilt may be significantly different even with little simulation differences.

No this is not yet possible. Please see our FAQ How can I include an inverter in a Stand-alone system?

There is now a way of defining the tariffs in hourly values on a CSV file.

No, there are no PVsyst distributors in any country. The company PVsyst SA is the only distributor for the whole world.

Yes, you can define a "normal" system with self-consumption and storage, and consider the energy injected into the grid as the heating energy of the hotwater tank. The battery sizing is completely dependent on your requirements (load profile, PV power and required self-consumption).

Such a system may easily be defined in PVsyst. You have all the required elements for that. You can get hourly data by defining a CSV output file (for EXCEL) using "Advanced simul > Output file". Here you can define the simulation variables you want to export.

No, this result is not available in PVsyst. The only way is to perform 2 simulations, with systems equivalent to each sub-array.

The simpler way is to redefine your inverter with 3 MPPT inputs, and attribute one sub-array to each input. The mismatch between orientations (i.e. between strings in different orientations) is usually very low (a fraction of %). You can check this by defining one sub-array with a "mixed" orientation. Here the calculation is correct, as it uses the mix of both I/V curves.

Yes, if you define a "table" or an array of "tables", you have the opportunity of giving a slope to the baseline of your table. However this will change the orientation of your plane. See the FAQ "With sheds on a tilted roof, PVsyst changes my orientation"

Yes, this means the proportion of data coming from Satellite data.

The "Module quality loss+ is a parameter at your disposal, for any purpose. Only the default value proposed by PVsyst is based on the PV module tolerance specification. Please see the FAQ How to define the "Module quality loss" ?

This is really strange as this file should not be located here, in any way... This is the second case of this problem. I don't know how this could arise. Please delete the PVsyst.INI file, this should solve the problem.

This is really strange as this file should not be located here, in any way... I don't know how this could arise. Please delete the PVsyst.INI file, this should solve the problem.

A gain due to the low-light efficiency is possible, especially in very sunny places. However this usually indicates that the PAN file has been specified with a very high series resistance, resulting in high low-light performance. See the FAQ How are specified the PAN files in the PVsyst database ?

I really don't see how this could arise. Please send us an example, at support@pvsyst.com

What you need is indeed provided by the "Grid system", using the "Grid storage" option, "Peak shaving". However this option doesn't define a DC converter in parallel with the Inverter yet. The Inverter is supposed to deliver the extra-power for the battery, so that it should be sized for accepting the peak power during the best days. We will develop this feature in a next version. In the mean time, the results with an oversized inverter sould be quite equivalent to a separate DC converter.

You can define different conditions from simulation to simulation using the Batch mode. Each simulation may produce an Hourly CSV file. But these resulting hourly CSV files will be independent. If you want to gather them in one only file you have to do that manually.

You can indeed import the POA measured on your trackers. But be careful: this measurement is subject to the same mutual shadings on the diffuse part than the value calculated by the simulation (linear shading loss on the loss diagram). So this measurement is not really suited for a good simulation. The best way is to use the measured Global horizontal. If you have also the diffuse at disposal, this is indeed the top for the accuracy of the transposition models. Now the Rear side irradiance measurement is extremely delicate, as the reflected irradiance is not homogeneous behind the tracker. In the present time this measurement is not useable as input for the simulation. The relationship between this value and the GlobBack calculated by PVsyst is not well established.

This is an artefact of the one-diode model. For numeric reasons, I had to limit the Diode Saturation current at a threshold value of 0.01 pA. When limiting to this value, the muPmpp becomes positive. This arises at very low temperatures, when you define a Rseries value close to its maximum RSMax. I judged that below -10°C, this remains acceptable. By the way even if the muPmpp becomes positive the one-diode model still works correctly. Simply the Pmpp doesn't increase anymore when going towards lower temperatures.

TArray and TArrWtd are based on the same TArray hourly data. Only the way of averaging these data is different: - TArray is a simple average of all values when the system is working. - TArrWtd is an average weighted by the irradiance: TArrWtd = Sumh (TArray * GlobInc) / Sumh (GlobInc) where Sumh = sum on hours

This is indeed an erroneous situation within the original Meteo data. PVsyst should normally check this at the import time. But the import of each provider is different, and perhaps this has not been checkd during your import. Moreover these checks have significantly evolved since this old version 6.43. NB: If you want to use these data, you have to correct them in the original meteo data file, before importing them.

The PID is not taken into account in PVsyst. We don't know any model describing this loss, which varies along the system life according to operating conditions (and module's quality !). If you want to take it into account for a particular year, and you know its amplitude, you have to specify it either as a LID loss, or with the "Module Quality Loss" parameter.

For defining arrays of trackers, you should use "Create > Tracking PV planes" in the main menu of the 3D editor. It is not yet possible to distribute trackers in a zone. If you define tables (sheds) in a zone, you can modify the tilt angles globally by selectring the desired tables, and use "Edit > Modify selected objects" in the main menu.