André Mermoud

I didn's say that the transformer loss is not significant of course. What I meant is that the choice of the STC PnomAC has not a significant effect on the evaluation of the transformer loss.

This is not yet implemented. See our FAQ Can I include a battery in a Grid-connected system ?

As you pointed out, when not present in the data the DHI is evaluated using the Erbs model. For the very high zenith angles (low sun height on the horizon), the DNI is indeed not well defined. If its value becomes too high from the GHI/DHI values, it is limited to the clear day model. This is especially the case when importing POA values. If the time definition of the data doesn't correspond to the time used for the calculation of the solar geometry, we can have very high uncertainties in the morning or the evening. This is the reason of the "Time shift" correction in PVsyst.

This was indeed an error in the version 6.46 (only this version), which has been corrected in the next versions.

Yes if you want. But this has a very weak significance: the STC PnomAC value is just here for a definition of a Reference Power.

You are right. By definition, with backtracking there is no mutual shadings for the beam component. Therefore the "Linear shading loss" will be 0 for the beam component, and defining Electrical losses is not necessary.

In PVsyst, a sub-array concerns one (or several) MPPT inputs. Each sub-array is supposed to be "homogeneous", i.e. same PV module, same number of modules in each string. Therefore you cannot simulate these situations in detail and rigorously with PVsyst. For the mix of different modules, you can eventually define an "average" module with the STC characteristics (Pmpp) corresponding to a weighted average of your modules distributions. Or you can also redefine your inverters as several "dummy" Multi-MPPT inverters, to be attributed to different sub-arrays with different kinds of modules. If you have 10 inverters, you can simply define different sub-arrays, each with an "homogeneous" set of modules. NB: mixing strings of not too different modules in parallel should not induce significant mismatch losses. The mismatch loss in voltage (parallel strings) is usually very low.

The PVsyst simulation only works in hourly values. If you have sub-hourly meteo data, you can import them in PVsyst (using "Tools > Import ASCII meteo files"), but they will be converted into hourly values.

For the Batch mode, each parameter should be explicitely specified in the programming. We did not implement this for monthly soiling. This is not really easy in this case, as this represents not one, but twelve parameters to adjust.

You cannot do that. The efficiency is a "little" correction to the Thermal energy balance. The U-value is a rough estimation of the themal balance, with a high uncertainty. If you try to estimate the efficiency from the temperatures, the uncertainties on the U-value - and the temperature instantaneous values - will give completely erratic efficiency values.

No sorry. This is not possible in the present time with PVsyst. The "Tools > Tables and graphs of Solar parameters" don't include tracking angles yet.

The overpower temperature dependency is referred to the inverter temperature. Now you can specify the inverter temperature behavior during the simulation (ambient temperature, ambient with shift, fixed room temperature) in the "Miscellaneous tools", page "Inverter temperature"

The main differences between these different runs probably come from the Diffuse part in these data. The transposition (i.e. the GlobInc/GlobHor ratio) is highly dependent on the Diffuse fraction, whatever the model used.

All the versions of PVsyst are compatible with Windows 10.

Yes of course. The best way is to open an existing (similar) module, and change the main parameters (STC values, Number of cells in series, sizes). All other parameters may be let at their default value (check the corresponding checkboxes). Finally save the PV module with a new filename, this will create a new module in your database. You can have a look on the FAQ: How to establish the PAN files?

The shed object is a "stiff" object: it cannot be adapted to a terrain. You should define your system as independent "tables". These tables may follow the terrain (base slope).

This value is simply the Pnom array, multiplied by the efficiency of the inverter at this power. This is not a very sensitive value. In a future version (not the next one), we will change this way of estimationg the Transformer losses and propose a more understandable procedure based on "real" transformers properties.

You can simply suppress all the losses after the inverter (AC and external transformer) in the simulation.

When you elaborate a 3D shading scene, and exit the editor, PVsyst will check that your scene is compatible with the other parts of the system. In particular, it will check that you have defined a sufficient active area (3D fields) in the 3D scene for positioning all modules defined in the "System" part (Subarrays area = sum of the areas of all modules). You can define a greater area in the 3D scene, as your modules may not be completely jointive, but not a smaller one. The match should be satisfied for each orientation. This screen shows the effective areas defined in the System and the shadings part. If you need more details you can find them with the button "System Overview".

The "Warranty efficiency curve" of most PV module's manufacturers show a warranty beginning with 97 or 98% guaranteed efficiency for the first year. In PVsyst, for one module this initial performance loss is mainly represented by the LID losses, which is a real degradation occuring within the first hours of exposure of the PV modules to the sun. There may also be a contribution of the Power tolerance, or you may want to take the Flash-test accuracy (not better than 2-3%) into account. Please ask the manufacturer for this interpretation. The option "Module quality loss" is more suited for taking this initial uncertainty into account. The LID loss or Module quality loss are applied to any simulation, for any year: the PV modules are "damaged" at the beginning, and stay like this all over the system's life. Parameters of the Ageing Tool Please note that the manufacturer's curve gives a Warranty for one module. It doesn't mean that the degradation of all modules will behave in this way. The average degradation for the whole system (average of the modules) will probably be much lower (this was reported as about -0.3% to -0.4%/year, by the very few studies about long-term degradation, and for very old modules). As all the modules will not degrade in the same way, the degradation loss will also be affected by the increasing mismatch between modules along years, which you can model in this tool, using a Monte-Carlo stochastic method. Simulations Simulation without specifying an ageing degradation: this "usual" simulation will represent the system's state at the commissioning time. It includes the initial LID loss. Simulation with ageing, for the first year of operation: this will also include the specified initial LID loss. If you specify a degradation rate of, say, 0.4%/year, then at the beginning of the year the degradation will be null, and at the end it will be 0.4%, therefore an average of 0.2% for the global simulation of the first year. The tool "Degradation" in the detailed losses gives the opportunity of performing the simulation for any given year after commissioning. In the "Detailed Simulation" option, you can perform a simulation over all (or several chosen) years, in order to get a summary of the yield of your system along its lifetime.

Please send us this SolarGIS file (to support@pvsyst.com)

This has been corrected. Please update to a more recent version.

I don't know. Please send us (support@pvsyst.com) the whole project (using "Files > Export projects"), and explain exactly where and how you find this problem.

Sorry. This has been corrected (and dialog improved) for the future version 6.49.

This is not the right way. The balance of self-consumed and injected power has to be done in hourly values, otherwise it doesn't make sense. Therefore for getting reliable values it is necessary to provide a representative hourly distribution of the consumptions during the year. You can do that either by importing a file of hourly consumption values for the full year, or by creating a generic hourly distribution during the day (i.e.choose "Daily Profiles" in the load definition). You have the opportunity of defining a different profile for the week-ends.