André Mermoud

The long-term degradation is applied to the STC values for the PV module model (50% in current, 50% in voltage), and therefore slightly affects the operating voltage. However in the case of your table, the Array voltage attains the Inverter VmppMin, and is therefore clipped to this value. This is the array operating voltage, not the MPP voltage. The impact of the degraded voltage in the simulation is simply the possible increase of the loss due to voltage threshold. NB: The degraded module is defined during the simulation process. There is no tool for analyzing this degraded module explicitely. You can create this degraded module by redefining the STC values Isc, Voc, Imp and Vmp. NB: I don't know any publication about the impact of the relative degradation on the current and the voltage. I have put an equivalent decrease for I and V, but without experimental justification. You may have defined night losses in your system, like Auxiliary consumptions or transformer iron loss.

Meteo data for very high latitudes (where the sun is low on horizon, or even not apparent during the day) are sometimes difficult to manage with the usual models. If with the imported Meteonorm data, you have problems like this one you can modify the limits in the "Hidden parameters". In this case: topic "Miscellaneous: Meteo, Simulation, ... ", item "Best KtCC days have strongly high values".

This problem should be corrected in the version 6.46 or 6.47.

This is a bug that we are investigating. It willl be corrected in the next version 6.48.

This depends onthe version you are using. This tool for importing Load profile in hourly data has been completely renewed in the version 6.44. The new file format is completely described in the help, and you have a template in c:\Program Files (x86) \ PVsyst6 \ Data \ UserData \.

This warning means that for the efficienciy curves according to 3 voltages, you have specified a voltage outside of the Vmpp window (888 to 1275 V in yoiur case).

This was indeed a bug just in the Version 6.44, when using tracking systems: the simulation reverted to the Hay model even when specifying the Perez model. The simulation was consistent with the report mention. This has been corrected in the next versions

This was indeed a bug just in the Version 6.44, when using tracking systems: the simulation reverted to the Hay model even when specifying the Perez model. The simulation was consistent with the report mention. This has been corrected in the next versions.

You can get the status of your update rights in the main menu "License > Status and Activation". If these are no more valid, you have to buy a renew of these rights for one year on our site www.pvsyst.com.

The GRef and TRef are the values for the definition of the model according to Isc, Voc, Imp and Vmp (normally the STC values). Now the operating condition Goper is normally not limited. If so, please tell me where in the software. The operating temperature should not be lower than -20 to -30°C. Below these values, I don't know how the one-diode model will behave. Usually, the diode Saturation current becomes quasi-null. For calculation reasons, PVsyst put a lower limit (0.1 pA), and the behavior of the one-diode model is slightly altered (namely the temperature coefficient becomes positive).

In the presizing - and everywhere in the software - the area is the area of the modules themselves. There is no direct tool for this evaluation in PVsyst. You can evaluate the desired GCR (according to the tilt and acceptable shading losses), using for example the "Unlimited sheds" option. The you determine the effective available ground area (taking the roads and other specificities into account). The pre-sizing active area will be the ground area times the GCR.

You have to contact our administration admin@pvsyst.com.

All optimizers have different characteristics, and each one requires a very special development in PVsyst. These developments have been done for some technologies, and rely on parameters specified by the concerned manufacturers. They are not customizable.

I don's see any reason for such an increase of this loss as a function of the temperature. If there is a depency it should be almost unsignificant. This may be an error of the simulation, that we have to analyze in detail. Please send your full project (using "Files > Export project" in the main menu) to support@pvsyst.com.

The LID loss ("Light Induced Degradation") is a phenomenon specific to Crystalline modules (and only with P-type bulk wafers). It is due to the wafer quality, namely traces of oxygen, which recombine with doping atoms during the first hours of exposition. It is not taken into account in the flash-test at the output of the factory, and therefore in the sorting process. Therefore it has to be taken into account in the simulation. The LID loss is sometimes specified in the datasheets, but not very often. When applicable (crysrtalline modules with P-type wafers) the usual value is around 2%, this is the default in PVsyst. Now in PVsyst, you have to define the LID loss explicitely in the "Detailed Losses" dialog. You can choose the value of your PV module if it is specified with the PAN file, or you can ask for the default value. The thin film modules (especially amorphous, but also CdTe to a lower extent) are known to degrade during the 2-3 first months. The "sold" nominal power is indeed the STC performance after stabilization. Therefore there is no additional loss with reaspect to the one-diode model during the simulation. NB: The "gain" before stabilization is not acounted in the simulation, as it is considered as a temporary behavior.

In PVsyst, we consider the light soaking effect as a temporary effect. The "pre-light soaking" period is sufficient short for neglecting it in the annual yield. Nothing is foreseen for taking this initial loss into account.

In the "Orientation " part, this is a rough tool for a quick evaluation of your orientation with respect to the optimal. This quick calculation is based on a simplified model based on the monthly meteo data only, without full accuracy. Moreover, if your meteo data (*.MET file) are not complete year, this tool will use the data defined in the "Project's site. The data on the report are the result of the hourly data simulation, these are the reference results.

Sorry, I don't undertand. In your first mail you talked about a tracking system, and here it seems to be a fixed plane system. Please remain coherent in your requests.

For using Backtracking, you have to define a corresponding 3D scene. The Backtracking parameters (pitch, tracker width) will be defined by your 3D construction.

When you import an ASCII meteo file, the program should know where is is situated, this information is provided by a *.SIT file. And the *.MET file will indeed contain a *.SIT object for its localisation. Now the presence of the *.SIT file in the database is necessary for creating a project. But it is not necessary for using (visualizing) the MET file: you can suppress it in the database if you want (you should manually suppress the file, there is no tool in PVsyst for that).

The backtracking for 2-axis trackers is a very complex problem, and there are several possible different strategies. In the present time, the PVsyst algorithm is quite insufficient, and you are not advised to use it. It only performs the backtracking in azimuth (with tilt set according to the sun's height), and without going to the "north", i.e. blocking the azimuth to values < 90°. When the sun goes to higher azimuths, the backtracking should switch to a backtracing in tilt (i.e. the next tracker sees "above" the preceding one). This is not done in PVsyst as we could not find a suited analytical algorithm. At this stage, one of the problems is: when should the system switch between the azimuth and the tilt strategy? This will induce a discontinuity on the tracking orientation: at a given time, the trackers will suddenly pass from an orientation to another one. With such a behavior, the system should come back to the Azimuth strategy (at values higher than 90°) symmetrically with respect to azimuth = 90° (West or East). Now a second problem arises with multi-rows arrays. In this case we should also implement the backtracking between 2 rows (one behind the other), which even may have a shift in E-W direction. Mixing this with the E-W BT strategy becomes a diabolic problem. We don't see any way of modelling all these behaviours analytically. The only solution would be to implement an ajustment by trys-and-errors, which may become time consuming during the simulation. We did not yet develop such an algorithm in PVsyst up to now.

You can import POA values in PVsyst. PVsyst will use a retro-transposition model for recreating Horizontal global and diffuse values for use in the simulation. Please use "Database > Import ASCII meteo files", and here you have the opportunity of choosing the Plane irradiance in the importing protocol.

The shading scene is a part of the calculation version. If you export a project, it will be included in the calculation versions which involve shadings. The *.SHD files are not associated with a specific project.

If you have already imported a terrain (from a CSV file), you can indeed use the "Zones" for positioning the tables on this terrain. However this works only with a specified pitch. I don't know any software adjusting the pitch table-by-table in order to get a constant limit angle. This seems indeed very difficult to do that on a "random" terrain, as the rows may become completely erratic. I don't know if Helios3D performs this operation, but i don't thinks so. All the helios3D drawings I have seen have perfectly aligned tables. NB: The batch mode allows to vary some specific parameters, not to do everything you could imagine. Each modifiable parameter has to be specifically programmed.

Probably you want to Export from PVsyst, not to Import these data. You can create a csv file of hourly or daily values for any variable of the simulation, for use in another program like MS Excel. Please use the button "Output file" just before performing the simulation. Here you can also specify the units.