André Mermoud

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.

This part of the report gives indications about the system, taken mainly from general features of the 3D scene. Of course if the system is complex, with different pitches or sizes, or different groups of sheds, this determination becomes unsure and very difficult to evaluate. It is quite impossible to give accurate measurement of any complex system. Should we completely suppress it when ths system is not "perfect" ? I don't think so, but people should understand that the values are only indicative.

The thumb rule is to consider a shading object as "Far shading" when it is at a distance of at least ten times the sizes of your PV system. So if your PVsystem has a size (width or length) less than 27 meter, you can indeed use the "Far shadings". In the opposite case, you can create a ground object for simulating your mountain. Don't define a too detailed grid as the calculation time may become prohibitive. Don't forget to check the option " Enable shadow casting" in the object's properties.

In PVsyst, the parameters of all trackers should be identical. So that at a given time, the orientation of all trackers is the same. Therefore it is not possible to distribute trackers on a hill, with axis following the slope. We will develop this feature in a next version. But in this case the backtracking will be totally impossible (either in PVsyst and in the reality).

This depends on the version. In the latest versions you have indeed the item "SAM CSV format - Hourly TMY or time series".

This depends on when you evaluate the solar geometry. In PVsyst, for normal intervals the geometry is computed in the middle of the hour (eventually shifted for some measured data). Now the first interval of the day begins at the sunrise time (say, 6:20). And the solar geometry is evaluated in the middle of this interval (in this case 6:40). I don't know whether the Synthetic generation managed by Meteonorm uses this convention. Please ask the Meteonorm team.

This service has been suppressed by PVGIS in october 2018. It is no more supported. PVsyst can now import CM-SAF data in a new format, as hourly files, directly from the PVGIS site. Please choose the option "PVGIS V5 Hourly time series"

PVsyst can import meteo data from many sources, in many formats, and creates internal *.MET files. But it doesn't create files in external formats.

SolarEdge has very specific and constraining rules. These rules involve specific devices (inverters and optimizers) and their associations. These are implemented in PVsyst according to the requirements of the SolarEdge team. Please ask them. NB: There will be a new implementation of these rules in the next version 6.80, with some new devices.

The irradiation conditions in the nord of Chile are really exceptionnal (due to altitude and very dry weather). You should increase the limit for this warning in the Hidden parameters, topic "Sites and Meteo", item "Upper limit for monthly clearness index"

Perhaps you are using an old version. In the Weak grid definitions you have this option: Group "Operating conditions", checkBox "Allows solar injection into the grid."

Usually no more than 1-2 working days.

There is a short explanation in the help "Project design > Shadings > Near Shadings: Import > Helios 3D" But we should indeed write a complete description of this tool.

Before analyzing the economic evaluation, please analyze first the energy output of your simulation. I don't understand well what you have specified on your CSV file: with CSV reading, PVsyst only accepts hourly consumption values, not daily values. If you want to create a PV system ensuring 100% self-consumption, it should be of sufficiently low power for never exceeding the User's needs, even by clear sky conditions.

For importing PVGIS data, PVsyst now uses a "Web service": it reaches directly the PVGIS site, and downloads the requested data. You don't need to open the PVGIS web site anymore. NB: With this new service, the PVGIS database has been deeply updated. The data are now provided in really measured hourly values, either as real years, or as TMY.