André Mermoud

I don't know. 15 kW/200MW represents 0.0075%. This may be a rounding error somewhere.

I have never seen that, and I can't reproduce it. This may indeed be related to a Windows setting (in "Internationalization"?) . - Does this arise with all projects ? - Does the date appear correctly in other dialogs (for example in "Tools > Meteo Tables and Graphs", box "Dates") ?

The reading of custom Horizon files is really very restricted. Only the first line may be a comment. The next lines should be values Azimuth; Height; We have indeed to modernize this reading for allowing a more flexible reading.

Sorry, the general treatment of tracking systems have not been developed in the "Tools" part, neither in the "Tables/graphs of Solar parameters" nor in "Monthly meteo computations".

You can convert these files by opening them in a new version (> V6.40), and save them using the option "File compatible with old versions" in the saving dialog. You can also ask the manufacturer for sending files in the old format.

Please check that you have also suppressed the bifacial system use in your other sub-array (LED switched OFF).

You should send your questions relative to errors at support@pvsyst.com

This was a beta-version. Please update to an official version.

This was in the V 6.61 only. It has been corrected in the version 6.62.

You can get a table of monthly values with any customized variable in "Results > Tables". Now adding custom variables on the monthly table of the main report is not yet possible, this is on our (very long) ToDo list.

Please see our FAQ How are managed the new "Twin modules" with half-cells ?

In PVsyst, the azimuth is defined as function of the geometric "true" North (or South) , i.e. parallel to a longitude line.

Sorry, this is not possible in PVsyst. I don't know if we will implement that for Tigo optimizers.

The new technology of "Twin half-cut cells" is more and more frequent on the market. These modules involve half-cells strings, mounted in the following way: Twin-module with half cells architecture Electrically, these modules are made of 2 strings of half-cells, mounted in parallel. In the PV modules definition, this should be defined as "Twin half-cells" layout, 60 (or 72) cells in series and 2 strings in parallel. One of the advantages waited from this configuration is an improvement in the mismatch under partial shadings. How can this new module configuration be taken into account in the PVsyst shading calculation ? First of all, we will only consider "regular" shading situations, when the shades affect all lower submodules at a time, i.e. mutual row shadings in sheds arrangement (portrait disposition, modules in portrait of one string on a same row). In this case as soon as the lower half-cell is shaded the lower submodule becomes completely inactive (for beam component), and the string current will be half the "normal" current (upper sub-module). This is the key point of the benefit of this configuration. This should be taken differently into account in the different ways PVsyst evaluates the electrical shadings: - In the "Unlimited sheds" 2D calculation, where the electrical shading loss is considered complete as soon as the first bottom cell is shaded, we can simply consider loosing half the module instead of the full module width. This option asks for the number of strings in the width of the row. We can simply double this value for twin modules (i.e. consider 2 rows for one module in portrait). This doesn't require any program modification and the calculation is correct. - In the calculation "according to module strings", the rectangle-string becomes inactive when the rectangle is hitten by a shade. In our case the halfmodule lower row behaves as a string: as soon as a part of it is shaded the half-modules doesn't produce anything more for the beam component. Therefore you can define the "rectangle-strings" size as half the size of the module. This is only true for one row of modules: in you have several rows (for example U-wiring), this is no more true and the situation becomes much more complex (with reduced gain on the losses). In the present time with normal modules, there is a correction for sheds arrangement: when the bottom cell is partially shaded, the remaining current should be proportional the the enlighted part of this bottom cell. In practice, PVsyst accounts for electrical shadings only when half the bottom cell is shaded (correct on an average over numerous situations). This correction becomes a little bit optimistic as it is applied on a cell which is half the size. - With the "Module layout" calculation, the calculation of the I/V curves becomes more complex. It has been fully implemented in the Version 7. Here there will be a tool for deeply understanding the real electrical effect of the partial shades. In the old versions (V 6.xx) the Twin modules are defined in the same way as usual modules in the ModuleLayout part (3 sub-modules in length). Therefore if you mount them as portrait, they will have slightly higher mismatch losses than the landscape. Cells temperature Now some people are wondering about the cell's temperature, and if it should be lowered in the model due to half the current in each sub-module. I can't imagine why, physically, the cell temperature should be lower than in normal PV modules. The current is half, but in half a cell. Therefore the current per cell area is the same. Now if you have scientific papers with reliable cell-temperature measurements (differential between normal and half-cut modules), please send them to me. Moreover I don't know the exact relation between the currents in the cells and the module temperature. This should be very low as to my understanding, the temperature elevation would be due to the power loss Rs * Ioper². Now Rs is around 0.3 ohm for a usual PV module, therefore the power loss is 24 W for Imp = 9A (and 6 W when operating at half-irradiance). If we assume an irradiance of 1000 W/m2, this module of 1.6 m2 will receive 1600 W, the current loss is 24/1600 = 1.5% of the irradiance, i.e. roughly a contribution of 1.5% to the U-value (and 0.75% under 500 W/m2). PVsyst desn't pretend to provide default U-values with this kind of accuracy. By the way, this Rs loss is already accounted in the thermal balance equation, as this equation accounts for the efficiency. Now if this is really the case, the benefit will probably be exactly the same in hot and cold climates, as the temperature correction wiil be added to the module temperature whatever the original temperature, and therefore lead to similar power differences.

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.