André Mermoud

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.

I don't see how you have evaluated these loss percentages. By the way the mismatch losses are not cumulative, as each of them implies a displacement of the Pmpp on the I/V curve. You have a detailed tool for studying the mismatch between strings: In the system dialog, "Detailed Losses > Module quality-LID-Mismatch", you can press "detailed study". Here you can press F1 for a description of the Mismatch problematics. Usually the mismatch between strings (in voltage) is extremely low.

PVsyst doesn't take this difference into account in the present time. We are preparing the feature for a next version.

It is noted in the Help that the copy of Graph's values to the clipboard is not always reliable. It depends on how the graph has been internally constructed. You should consider this as a facultative bonus, and be happy when it is available...

When there is a bug in a version, we cannot modify this version in any way. If there is no workaround, you can: - either upgrade to a more recent version, - or revert to a preceding one. You can always download and install older versions from our site www.pvsyst.com, and install them in parallel with your working version. Both versions use the same license.

The LID loss is obviously not recovered after some few hours. If you have a module of, say, 300 W, and a LID loss of 2%, the module will deliver 294W after some few hours. But there is no reason that is gives 300 W again at the end of the year! The LID loss is a permanent loss, for the whole life of the module.

This is not a bug. During the simulation, the GlobInc threshold is used as an indicator for the night time. Setting it to 0 is incorrect.

The development of the SolarEdge systems has been done in close relationship with SolarEdge. SolarEdge edicted very complex rules for each of their components and associations of components. PVsyst strictly applies the requirement of these SolarEdge rules. Please ask SolarEdge people for the reasons of these constraints.

The "Miscellaneous tools" button has simply been renamed as "Energy management", which seems more appropriate in this case. The features inside the button are unchanged.

The right way is to sum all the values of the numerator, and all the values of the denominator. I.e. divide the sum of all E_Grid by the sum of all (GlobInc * PnomPV) products.

No, this is not possible. By the way I don't see well which kind of usual application would have energy needs just corresponding to the PV production at any time. The only practical case I know is the pumping, where the pump's power may be modulated according to the sun's availability at any time. PVsyst treats such pumping systems. We could also think about some air-conditionoîng units, but I really don't know any suited device for that.

For the interpretation and difference between the project's albedo and the Bi-facial albedo, please see our FAQ "What is the effect of changing the albedo in the project ?". Now the mention of albedo in the Horizon part is not another definition of the albedo. This is an interpretation - and correction - of the project's albedo in shading situation. If you have an obstacle (far shadings) rather close to your system, the albedo of the terrain in front of this obstacle may be diminished due to the fact that the irradiance is lower for this area (ie the terrain is in the "shade" of the sun), and this area is not so extended as an "unlimited" terrain. For details, please see the Help "Project design > Shadings > Far shadings - Horizon", especially the paragraph "Treatment during the simulation process".

The main aim of the forum is to provide a communication link between PVsyst users. If we have taken the habit of answering many questions, it is not an obligation. I was personnally very busy these last weeks, so that I indeed neglected this channel. When you have specific questions (and especially bug reports) the normal channel is our support@pvsyst.com service. NB: I don't understand well the assertion "No proper documentation for updates". It seems that we do our best for documenting the evolution of the softtware, with the release notes, the help, the FAQ, some tutorials, etc.

This is not so simple. The irradiance on the back side is the result of a complex model, which is fully explained in the Help "Project design > Bifacial Systems". Please carefully read it. In the results the irradiance on the back side is named "GlobBak".

PVsyst doesn't manage negative plane tilts. A tilt of -25° towards an azimuth of -90° corresponds indeed to a tilt of +25° towards +90°. This erroneous generation takes place in the Sketchup import file. We will manage for correcting such a situation in a next version of PVsyst.

Micro-inverters are distributed devices managing usually 1 PV module, sometimes 2 or 4, directly connected to the grid. Some people are waiting for a big gain of productivity with this configuration. The maximum gain we can wait with respect to a "normal" system will be: - A part of the mismatch due to different modules (if 2 or 4 modules in series, there may be still a mismatch between them). - A part of the shading electrical mismatch loss (to be evaluated with the "Module layout" tool in both cases). But other features may represent a worst behaviour: - The wiring loss will be distributed between the DC and the AC parts up to the injection point. With Micro-inverters you have no wiring losses on the DC circuit (or very limited with 2 or 4 modules); but you have AC losses on a long way under 240V. With centralized systems, the DC circuit is usually working at high voltage (500-700V), reducing the wiring loss (for a same wire section) in a part of the distance. The AC loss only concerns the distance between the inverter and the injection point, and may act on a 3-phased circuit (less current). - Usually a big inverter has a higher efficiency. This has to be included in the comparison.

No sorry, the flow batteries are not yet implemented in PVsyst. Each battery technology requires the development of a detailed model, and we did not study this technology up to now. However this is not very important: you can replace them by a Li-Ion battery pack of the equivalent capacity (or even by the "Generic" battery). The storage in simulation involves energy fluxes (charge/discharge and their power converters). The way the energy is stored is not relevant, it doesn't have any impact on the energy balance, except for the charge/discharge efficiency and lifetime.

Your scenario corresponds indeed to a strategy of shifting the delivery to the grid with respect to the solar availability. This may be economically interesting only if the difference between the tariff during reinjection and the tariff during the solar production is higher than the price of the stored energy. Sorry, this strategy has not been implemented yet "as such". However it should be possible to use the "Grid limitation" strategy, with a very low grid limit.

The usual tracking strategy defines the tracker's angle in order to minimize the incidence angle for a given sun's position. This new strategy determines the orientation according to the best irradiance received by the trackers. This may be different than the previous strategy as the transpositon of the diffuse component is proportional to (1 + cos(i) / 2), where i = incidence angle. Therefore the higher tilt, the less transposed irradiance. For a fully covered weather, the optimal tracker's position will be horizontal (Phi = 0) In practice on real systems, this strategy may be easily applied by putting 2 irradiance sensors on the tracker, separated by a black wall perpendicular to the tracker: the best orientation is obtained when the measured irradiances are equal.

Some answers to your questions. 1. - I don't understand well your doubts. The fixed sheds are obviously usually aligned East-West, i.e. facing the south. Except when you are using domes. The single axis trackers have always an axis orientation close to N/S, for tracking the sunrise and sunset "sun's height" positions. An axis oriented E/W would only track the height of the sun on the horizon. It is not useable with PV systems. 2. - The "Edge effects" When you have 2 narrow tables one behind the other, in the morning or the evening a part of the shade is falling on the ground instead of the table behind. We don't have this situation in "unlimited sheds". 3. - Difference between "Unlimited trackers" and "Tracker arrays" defined in the 3D scene. The "Unlimited trackers" shades calculation (from tracker to tracker) is a 2-dimentional analytic calculation. The "Trackers arrays" defined in the 3D scene use the full 3D calculation of the mutual shadings from the sun's position. It is a much more complex calculation, taking the real sizes of the tables into account ("edge effects"). Now each of these very different calculations are using not quite perfect models, it is normal that there are some little discrepancies.

We don't envisage to develop a simulation of both options mono and bi-facial at the same time. As these would be 2 different systems, therefore 2 different sets of result variables, etc. This involves a very complex simulation process. I really don't see how to do that in PVsyst, and how to present it on a report. The right way is to perform 2 different simulation, and compare the results (eventually the losses, like for example the overload losses).

The bifacial model is rather complex (and specific, still involving "ulimited sheds"). It is not useable with stand-alone systems.

The integral for the diffuse involves an incidence factor of each irradiance ray on the receiving surface. I.e. each "cell" of irradiance should be multiplied by cos(i) (i = incidence angle). Therefore: - the effect depends on the plane orientation - It cannot be approximated by surfaces on the sphere.