André Mermoud

PVsyst doesn't manage the minimum starting voltage specified by some few manufacturers. Usually this is below the VmppMin and I don't understand well the mechanism. In your case of a value far above the VmppMin, we can understand that when the array is not operating, it is at Voc, not Vmpp, so that this constraint is perhaps less important. However, please ask the manufacturer for details about this behaviour.

You have indeed to perform a simulation before activating the Bifacial system. This was an error in the version 6.76. Corrected in the new versions.

This was an accident, just in the version 6.76. Sorry.

If the Mechanical Phi limits are +/-60°, and the Backtracking limits are, say, +/-63°, then - when the calculated Backtracking angle is between 60 and 63°, the trackers are clipped to 60°. - when the sun continues to go down, the backtracking angle diminishes and the tracker will follow the "true" backtracking orientation below 60°. You can observe this behaviour in the tool "Orientation > Unlimited trackers".

Yes, there are only some few video tutorials for specific topics edited by PVsyst. Especially concerning the shadings treatment. You have another more complete tutorial, in Text mode, within the software. The other videos (not listed) are provided by other users.

You can of course perform your simulation for any operating year, taking the ageing losses into account. You will get the corresponding loss diagram. Now you can also perform the simulation for the whole desired operating period, using "Advanced simulation > Ageing Tool". The yearly evolution will appear on the report. I don't see of which O&M factor you are talking about. This doesn't involve an energy loss, but only an additional cost. This cost may be defined in the Eonomic Evaluation.

Please try to avoid special characters in the Filename.

You are right: the horizon evaluation is very sensitive to the exact position of the observer. However the coordinates specified at the import time are well determined (4-decimal resolution, i.e. 11m), so that the Horizon line is well established by the provider. Afterwards, loosing some accuracy on the project's position will not modify the horizon line, and therefore will not have any impact in your simulation.

Sorry, I don't understand well what you mean by "the availability of Flow Storage Batteries". During the simulation, PVsyst evaluates the flow through the battery (EBattCharge and EBattDischarge). This is a result of the simulation.

The calculation of the Performance Ratio is explained in our FAQ How is calculated the PR (Performance Ratio) ? In this equation, the E_Grid and GlobInc values are always taken as sums for the whole considered period. Mathematically, it doesn't make sense to average Performance Ratio values over different periods.

The *.MET file is meant for an internal use within PVsyst. In principle we don't ensure a complete maintenance and info about its parameters and variable names. The parameters you mention are not used in any way in this file. These are useful for other tracking types. For horizontal axis tracking systems: - The Axis azimut is named "AzimAxe" - The Phi limits are named "AzimMin" and "AzimMax". Thise values are set when you create the ASCII file, and act on the importing process. They cannot be modified afterwards of course. For the question of ReneeDegutis: The import of Meteo data measured on a tracking plane has been introduced in the version 6.73. This feature is not available in the version 6.68.

Backtracking calculation The backtracking orientation calculation is based on the geometry of a pair of trackers , i.e. the distance p between trackers, and the width w of each tracker. These 2 variables are supposed to be equivalent from tracker to tracker, i.e. only valid for perfectly regular arrays. If it is not the case PVsyst will calculate the backtracking for the less favourable pair of trackers, and this calculation may not be optimal for more spaced pairs of trackers: these will beging to "backtrack" before it is necessary, resulting in orientation losses. Inversely if you have lower pitch, or altitude differences, you will necessary have mutual shadings. In the present time, PVsyst doesn't calculate the backtracking for trackers at different altitudes. However even when we will implement this, the altitude differences will be necessarily the same for all trackers (i.e. the tracker array will be in a same flat E-W inclined plane). Moreover, remember that in PVsyst, when using the tracking option the orientation of all trackers is identical at a given time. On a Hill Now on a hill, when the altitudes differences are different from tracker to tracker, it is physically impossible to define a "pure" backtracking strategy. If you calculate the backtracking Phi angle between the trackers A and B, it will be different than for the trackers B and C, so that the backtracking cannot be optimal for both pairs simultaneously: either you will have residual shades, or the "back"tracking will begin before it is necessary. Some people propose a situation where all trackers take a different position: this leads to extremely complex calculations (the optimization of the Phi angle of each tracker should be performed simultaneously on all trackers for each sun's position) without ensuring a perfect solution. This optimization involves machine-learning techniques for a given installation. And the real gain may be questionable. As far as we don't have a model for the implementation of such a strategy, we cannot envisage this development in PVsyst in a previsible future. Moreover on the field, you should also wonder how you will physically implement such Backtracking control in your installation. Workaround / only way on a hill: give up the backtracking strategy. Please remember that basically the mutual shadings and "true" backtracking give very close irradiance results, as you intercept the same light tube. What you loose as shading losses in the first case will be lost as mis-orientation and IAM losses in the second case. See Which gain can I expect from backtracking strategy? Only the electrical mismatch shading losses give a significant advantage to the backtracking. The mutual shadings are quite correctly calculated by PVsyst with trackers on a hill. A not perfect backtracking will loose either by unexpected mutual shades, and by "early-back"tracking (leaving some sun rays unintercepted between trackers). So on a hill, there is no definitive solution. You have to simulate both situations (with and without backtracking) and chose the best result.

The clipping loss is not only dependent on the DC:AC ratio, but also on the strings distribution on different MPPT inputs. As an example if you are using inverters with several MPPT inputs: - when you use the option "Uses multi-MPPT", each MPPT input will be considered as an independent inverter with half-Pnom In this case, as an example, the MPPT with 2 strings may have overload when the MPPT with one string will not. - when you uncheck this option, the inverter will have 3 strings on 2 MPPT inputs, but the power may be shared so that you have no (or much less) overload. This is the real behavior of most inverters. This is explained in detail in the help "Project design > Grid-connected system definition > Multi-MPPT inverters: power sharing"

The eventual irradiance falling on the back side in indeed present whatever the system is bifacial or not. The U-values evaluated (measured) for usual installation already takes this into account. Therefore there is no difference between mono and bifacial systems.

This tool is not suited for importing shading objects of any shape, like a polygon. It defines a terrain area, i.e. an uneven surface. In this respect the terrain is defined as a set of triangles constructed on your 3D points. The order of the points cannot be pre-defined: it is set by an internal algorithm according to the points positions. There is no possible choice for that: this is a univoqie mathematical choice. This construction cannot be concave.

PVsyst doesn't allow backtracking with different tracker's altitudes. Even if you define pairs of trackers for the calculation of the backtracking angle, this doesn't ensure that you will have a valid backtracking between you pairs of trackers: you can have shades, or backtracking misorientation state without necessity. This is not a particularity of PVsyst, but the real world. There may eventually be a solution for keeping backtracking conditions with uneven terrain, but this implies evaluating a different orientation for each tracker, and the calculation becomes extremely complex, as all the tracker's orientations are interdependent. A company proposes such an algorithm, which requires informatic learning techniques, and doesn't guarantee the absence of shades in any situation.

How do you define your "Maximum export power" ? If it is a grid limitation, this is quite normal: when you have losses after the inverter, the inverter has to produce some energy more, for compensating the AC losses after the inverter and ensuring a specified power injected into the grid.

This is because you have already installed PVsyst on your computer previously. You have "burned" your Evaluation mode. Try with another computer.

If you want to obtain what you "know à priori", it is not the good way. Sometimes the real calculation gives defferent values than what you are waiting for. Now the optimization of the plane orientation for your site may be obtained in detail in "Tools > Transposition factor" (here, please press F1 for Help). However this optimization is different when you have a sheds (rows) arrangement, due to mutual shadings. For deeply understanding this, please use "Project design > Grid connected > orientation", and choose "Unlimited sheds". Open "Show optimization", and press F1 for explanations.

You can do that manually. It is very difficult to define an algorithm for filling the tables with any exotic constraints like this one.

This becomes very complex indeed. And the "recovery" through the transparency would be very limited due to electrical mismatch losses. Moreover the "recovery" would arise in winter, when the irradiance contribution is not very important at medium latitudes. We don't envisage to implement this in PVsyst in a previsible future.

In the present time the bifacial model of PVsyst is indeed limited to shed-like or tracking with horizontal axis installations, sufficiently large for neglecting the edge effects on the sides of ths system, as well as in front and behind it. However you can define a 3D scene (in sheds or trackers), and if you (and PVsyst) judge that this matches these hypothesis, PVsyst will allow to use this installation as basis. However for the bi-facial calcuation, it will construct a dummy "unlimited sheds" installation, as similar as possible to your effective installation. Please carefully read the help "Project design > Bifacial Systems > Bifacial systems procedure".

Perhaps you have used Half-cells modules ? We have corrected a problem in the Module layout calculation for these particular modules in the version 6.76.

This is indeed a bug. Which version are you using ? We have corrected such problems in some very specific situations in the past. Please send us the full project, using "Files > Export project" in the main menu. Send it to support@pvsyst.com, in order that we can analyze this problem in detail.

In the present time the bifacial model of PVsyst is indeed limited to shed-like or tracking with horizontal axis installations, sufficiently large for neglecting the edge effects on the sides of ths system, as well as in front and behind it. However you can define a 3D scene (in sheds or trackers), and if you (and PVsyst) judge that this matches these hypothesis, PVsyst will allow to use this installation as basis. However for the bi-facial calcuation, it will construct a dummy "unlimited sheds" installation, as similar as possible to your effective installation. Please carefully read the help "Project design > Bifacial Systems > Bifacial systems procedure".