André Mermoud

The bifacial system treatment is only valid for a full system, with rather homogeneous PV modules. In you case you have probably several sub-arrays, with different modules (bi-facial or not): PVsyst will take an average of the bifaciality factors of the different modules, weighted by the respective PnomPV of each Sub-array.

For the calculation of the backtracking angle, PVsyst has to use the pitch and wdth of 2 adjacent trackers. This is only possible with trackers of a same tracker object (array of trackers). When you have several arrays of trackers, PVsyst will choose the more "narrow" as reference.

The shading is accounted for the beam component (the shade what you see), but also on the diffuse and albedo components, which are integrals of the shading factor over all the directions "seen" by the PV module.

Your measured value corresponds to the GlobInc value (Incident global), which is just the result of the transposition from horizontal to your tilted plane. Th GlobEff value (Effective global) is the GlobInc, affected by the optical losses like Far and Linear shadings, IAM and soling losses.

In the Economic evaluation of stand-alone systems, you have a button "Running costs". In this dialog, you have an item "Provision for Battery replacement", and the information of the battery lifdetime, according to the effective use in your simulation.

I don't know how you have done your calculations. PVsyst offers a powerful way for the estimation of the PnomPV / PnomAC ratio, named PNomRatio. You can get this tool by clicking the button "Show sizing" in the "System" definition part. Please also see the help "Project design > Grid-connected system definition > Inverter / Array sizing". In practice, you don't have any overpower loss until a PNomRatio of 1.25 or even 1.3. Due to the low price of the PV modules, and the limitation of grid inection, many people now use highly oversized PV array (with PNomRatio up to 1.5 - 1.6 or even more). For such an optimiaztion you can use the PVsyst simulation, and evaluate separately the investment for the PV array and for the Inverter/connexions costs.

These are complex numerical calculations, with some approximations, tables, interpolations between tables, etc. Perhaps your table sizes (with inter-modules or mechanical frames) are not exactly scaled. There are also rouding effects in the Hourly values. Do you really think that differences of the order of 0.2% to 1% on the shading losses of diffuse (most of them less than 0.5 W/m2) are significant, when the modelling uncertainties of these factors are probably of several percents ? I find it indeed reassuring that the differences are so low.

The backtracking strategy is only possible with flat systems, where the trackers are at a same altitude. Backtracking between trackers at different altitudes is not possible in PVsyst, and doesn't make sense in the reality (except if you have a very special system with individual backtracking algorithm for each pair of tracker).

Sheds or tables are exactly the same: the "Tables" is our new vocabulary for defining one mechanical shed. A table is basically a mechanical frame, with an array of PV modules on it. The mechanical frame may exceed the PV modules (Frame Left/right/Top/Bottom). Now PVsyst sometimes uses "Sheds" for an array of tables, but it may also be an array of domes, etc. For very big scenes you are advised to use tables as big as possible, for diminishing the shading calculation time.

The main values are from the datasheets. The performance of the real components (which you receive from your provider) cannot of course be assessed by PVsyst. Therefore the PVsyst simulation can only be performed on the basis of the Datasheets parameters. Now for the additional parameters of the PV modules (like Rserie, Rshunt, IAM), which are not mentioned on the datasheets, we perform a careful check of the values proposed by the manufacturers, and require third-party measurements when deviating from the PVsyst default. See our FAQ How are specified the PAN files in the PVsyst database ? For the inverter's performance (like efficiency) we are on the way of proposing the mention of a certification from third party organisms when available.

You are right: this is not really clear. The PMax value shown here is not taken from the PNom (nameplate) value. It is the maximum Array power attained ubnder the maximum possible GlobInc, as calculated from the Clear day model in this plane porientation.

The hourly values are obviously part of the input Meteo hourly data (*.MET file). Now if you only avail of monthly values, PVsyst will use a specific model, the synthetic generation. Please see our FAQ What are the Synthetic hourly data ? Now for very special uses (especially for sizing tools) PVsyst sometimes uses an approximation which is a distribution established by the Clear day model, eventually renormalized to a required daily value.

This is indeed a problem which arises with some computers. It is related to the Graphic card, which is now used by the 3D editor. Some old drivers of the graphic card don't support the functions that PVsyst is using, without noticing this to the program You can either pass to the next version 6.61, or update the driver of your graphic card (this doesn't work in any case, very mysterious...).

This was indeed an error with not-south tracking systems, which has been fixed in the version 6.53.

Are you sure that you re-open the version 6.61 and not a version below 6.39 ? If so, please send us one of the *.OND file that you cannot open with the version 6.61. (send it to support@pvsyst.com).

You can calculates these values in this approximate way if you want. However PVsyst doesn't need these VMin and VMax values during the simulation, it calculates the effective Vmpp at each operating hour from the one-diode model. It only needs these values (as well as the Voc(TMin) at the desigh time, for the determination of the minimum and maximum numbers of PV modules in series. Please see the help "Project design > Grid-connected system definition > Array voltage sizing" for a complete explanation of this sizing process and the corresponding tool. And our FAQ How to adjust the design temperature ?

PVsyst doesn't use this approach of NOCT, which is extremely confusing. Please see our FAQ How to adjust the NOCT value? and also How is evaluated the module temperature during simulation ?.

You are right. This was a fundamental question when I did this difficult choice (perhaps 15-20 years ago). This was the case in very old versions (up to V 2.2 ?), but this lead to contradictions in the results interpretation and losses evaluation. However I don't remember exactly which ones, sorry. Probably with irradiance data already including the horizon substraction (i.e. measured data at a given place), when the horizon of the system is not the same. Or concerning the calculation of the effect on the diffuse component. NB: With the present choice, the horizon loss is included in the PR evaluation (referenced to the GlobInc value), which is not optimal indeed.

In PVsyst all results values are for the global system. The GlobInc value is the average of the 3 GlobInc values, weighted by the nominal power of each sub-array.

You are probably using SolarEdge optimizers with fractional inputs. There is a bug with these devices and this situation in the verson 6.60, which has been corrected in V 6.61.

No. In PVsyst the results are only available as global for the whole system. If you want an evaluation of each subsystem, you have to perform an independent simulation for each one.

Technically, I don't see how your system will work. If it is really forbidden to reinject electricity into the grid, your system will only run when the full production is indeed consumed internally. As soon as the consumption goes below the inverter nominal power, unless there is a very special control device within the inverter for running at partial load (I don't know any device of this kind), this will stop working. Now the unavailability tool is not suited for this use. You cannot define more than 5 periods. The only way is the definition of the load in hourly values, and discard the energy reinjected into the grid. In this case you can recalculate the PR by yourself according to your hypothesis. You can also create an hourly file when performing the simulation, and calculate your balances by yourself in EXCEL.

Please check that you don't have a too high Vmpp value. See the FAQ Why the overload loss sometimes increases significantly without reason ?

This is not the right way of taking the not-used energy into account. You should use the option "Net metering", and consider the energy injected ito the grid as lost energy.

Please simply read my previous post