André Mermoud

Please explain what you mean by "those factors which cn affect actual transposition compare to PV Syst". What is the "actual transposition" ? There are no hidden factors in the transposition model: only the possibility of using the Hay or the Perez model (defined in the project's settings, or the Hidden parameters if you are not within a project).

It is clearly mentioned in the Help that at the moment, the model available in PVsyst only applies to "unlimited sheds"-like systems, and with a significant number of sheds. The edge effects are not taken into account, neither in with, nor in the perpendicular direction (i.e. number of sheds). The pitch and collector width are basic parameters of the model. This means that the model doesn't apply to a single module or table on a roof. This feature will be developed in a future version.

Yes, most of the usual Solar converters work with a "Stop / Start" behaviour, based in the battery state, as it is done in PVsyst. Some sophisticated converters use indeed a more complex charging strategy: when the battery is full (i.e. attains the charging OFF threshold), they don't cut, but reduce the voltage appplied to the battery, and maintain it at a value ensuring a little current (floating mode). This has not yet been implemented in the simulation of PVsyst, it should be done soon. This mode could indeed be used for ensuring your proposition, which is to maintain the PV production when it is sufficient for covering the user's needs. This will require a special operating mode of the controller, which is to exactly adjust the output power for ensuring this floating voltage. In the same way as when limiting the output power of grid inverters, this will be obtained by displacing the operating point on the I/V curve. However if your battery is sufficiently sized (2-3 days of consumption), as far as you don't have to cut the load because it is discharged, the balance of the unused energy will be exactly the same. Because the Solar PV system cannot produce more energy than the user's needs ! If the battery remains charged during what would otherwise be the "battery cut", it will not need to be charged afterwards. The only difference will be the battery wear due to cycling , and eventual battery efficiency losses. You could indeed observe a (very small) advantage if you have to cut the user due to a complete discharge of the battery.

I don't see the principle. If you don't have a battery, and a "constrained" consumption in your DC circuit, this will comsume this energy whatever the origin (PV or grid) at a given time. Now if you have 2 counters (grid injection and grid consumption): if the reinjection tariff is higher, you have always advantage of counting your PV electricity as reinjected. In the opposite case, you have advantage to auto-consume your PV energy. There is no better intermediate case. In this problem, no need to assume a 400VDC circuit: you can think in terms of energy (internal load). For this evaluation, you can therefore use the "Self-consumption" option.

The LID is an initial degradation of the PV module's performance, arising during the first hours of exposition. It is obviously not "recovered" at the end of the first year ! The degradation is permanent, this means that it has indeed to be applied to each simulation for each year.

Yes this is now available. When editing the report, please choose "Settings > Report preferences".

The GlobInc value is not correct. It should be expressed in kWh/m2/day. Not kW/m2. If you have measurements every 15 seconds, you have to calculate the average irradiance for each hour (or the order of 1000 W/m2 if at full sun). Then you add all the hourly irradiances [W/m2 = Wh/h/m2] of your day and divide by 1000 for getting [kWh/m2/day]. The result should be of the order off 7-9 kWh/m2/day for a clear day and south-facing plane.

You can indeed try to define an array of 2 trackers for the calculation of the backtracking angle. And add individual trackers at different locations and altitudes to your 3D scene. In this case the backtracking will not be correct, you will have some mutual shadings. However these shadings will be calculated quite correctly by the simulation. You will have to perform the electrical shadings calculations as well (in mode "according to module strings" should be sufficient).

The manufacturer's ageing values are a warranty, i.e. a worst case value for one (each) module. The definitions for the degradation concern the whole system, i.e. an average of all modules. This is not the same thing. Please see our FAQ How to interpret the warranty efficiency curve of the manufacturers ?

I don't understand well the question. This product 174 kWh/m2 * 386518 m2 * 17.03% gives 11453 MWh. I.e. a difference of 0.25% with the value shown. This is a rounding effect.

In the present time PVsyst treats 2 specific kinds of Bifacial systems, which may be modelled using maily 2D calculations: - "Unlimited sheds", or 3D scenes which can be approximated by unlimited sheds - "Unlimited trackers" with horizontal axis, or 3D scenes which can be approximated by unlimited trackers. In a next step we will implement bifacial systems for any 3D scene, which involves a 3D tratment, more complex. The extension to other kinds of tracker is not foreseen in a near future.

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.