Bruno Wittmer

Dear allison.mueller, Just for clarification of point b): Did you try to change the AC losses in batch mode and it did not work, or did you change the variant and it did not save the changes as in a)? I tried to reproduce the behavior you describe in point a), but did not succeed. When I change AC and/or Transformer losses, and save the variant, it is stored correctly and I find the new values when reopening the variant. Could it be that you have several sub-arrays with different cable and transformer configurations, and that you changed only one of them, while the others remained the same? If that is not the case, could you please send us an example where this happens, so that I can reproduce the error and fix it? Please note also, that in batch mode you can only change the transformer resistance losses (copper losses), but not the iron loss. Therefore the global transformer losses will never become zero in the batch mode. Similarly, in the batch mode you can only change the AC cables between inverter and MV transformer, the MV line cannot be changed with the batch mode.

The variable GlobBak represents the effective irradiance on the rear side. It includes direct and diffuse sky irradiance as well as the irradiance reflected from the ground. For all these three irradiance components the shading and IAM losses are accounted for. The bifaciality factor is a property of the PV module. In the simulation it is applied when calculating the photovoltaic conversion, so it is not yet reflected in GlobBak. The calculation applies the bifaciality factor to GlobBak, and uses this result as input for the single diode model. For the thermal behavior the simulation uses the same approach for both, monofacial and bifacial simulations. In fact, the irradiance both modules receive is the same, the only difference is that the bifacial module removes a little more energy when operating, which would mean that its temperature will be slightly lower. This is not yet taken into account in the simulation.

Indeed there seems to be a problem with the bifacial tracking systems. The parameters of pitch and width are not correctly applied. @ckremin : Can you confirm that the system where you observe the discrepancy is bifacial? I also did checks on monofacial systems, and found consistent results between PVsyst V7.1.8 and V7.2.0. We will fix this issue of bifacial trackers as soon as possible and publish an update. We are sorry for the inconvenience, and thank you for reporting the issue.

I was able to reproduce this error. We will correct it, and add a post when the fix is released. Thank you for reporting the issue.

Currently the bifacial model in PVsyst that is used for trackers, allows only a horizontal axis and a flat terrain. The error message is not very clear on that, it should be improved. Allowing an axis tilt for bifacial trackers would only be useful in combination with a possible terrain slope, and both should be able to vary independently of each other. This will need considerable reworking of the bifacial model.

The bifacial models currently implemented in PVsyst (V7.1.3) are based on an approximation that is valid for long and regular rows. If you use a 3D drawing in 'Near Shadings', PVsyst will check that the PVsystem is based on a single orientation and rows with regular width and pitch (the row length may vary). If there is too much variation in the pitch, you will get an error message, saying that the bifacial model cannot be used in this case. This is valid for fixed tilt rows as well as for single axis trackers. This is also explained in the PVsyst help under: Project design > Bifacial Systems > Bifacial system: 2-dimensional unlimited sheds Project design > Bifacial Systems > Bifacial system: 2-dimensional unlimited trackers If your installation is fixed tilt on an irregular terrain, this typically leads to several different orientations. You may consider gathering all tables in a single orientation group, by using the tool 'Manage Orientations' in the 3D editor of PVsyst. In this case, PVsyst will calculate the irradiance transposition by using a single average orientation, while the shadings will still be calculated with all detail of the drawing. If like this you can get a single orientation group, and the row pitch is regulear, the bifacial simulation becomes possible with PVsyst. You should use this approach only if the variations in terrain slope are small, it is not adapted for hills and steep slopes. You should keep in mind that this will calculate only an approximation of the bifacial contribution.

Please see the answer to this topic

The bifacial gain can vary through a wide range, from a few percent up to 20% or more. A bifacial gain of 20% is quite high and can only be achieved in very special cases. The additional generation that you can expect from using bifacial PV modules depends on several parameters, the most important ones being: Albedo (the higher the albedo the higher the gain)Pitch (the larger the pitch the higher the gain)Mounting height (the higher the modules, the higher the gain The albedo is most crucial and can range from 15-20% for surfaces with little reflection up to 80% for freshly fallen snow. You can find a table with typical albedo values in the PVsyst help.

Irradiance treatment: circumsolar The treatment of the irradiance has been improved. We now distinguish a new irradiance contribution: the circumsolar (enhanced irradiance in a crown around the sun). This contribution was previously included in the Diffuse component, and treated as such in the shading calculations (i.e. isotropically). It is now evaluated from the Transposition models (it is about proportional to the beam component) so that we have now 4 irradiance contributions on the collector plane: Beam component, circumsolar, isotropic diffuse and albedo. NB: What is considered as Circumsolar ? This is indeed a difficult question. In all usual meteorologigal data, the circumsolar contribution is accounted with the diffuse component. When the diffuse is effectively measured, the instruments may measure: - Either the DNI in a cone of 5° around the sun (the diameter of the sun is 0.53°). The circumsolar contribution, as interpreted by the transposition models (Perez or Hay) is the irradiance outside of this cone. - Or by a solarimeter with a rotating cache, which should correspond to this 5° cone (but very difficult to manage correctly without sophisticated tracking instruments) - Or by a solarimeter and a shadowing band, with some uncertain corrections. Now when establishing the diffuse with a model, the Perez model for the diffuse (DirInt) produces of course a diffuse compatible with these hypothesis. The additional "Circumsolar" contribution is evaluated in the Transposition models (either Perez or Hay). Use in shading and IAM calculations In PVsyst the circumsolar is now treated in the same way as the beam (i.e. coming from the direction of the sun). This means that the Shading loss on isotropic diffuse is lower, and the shading loss on beam + circumsolar is higher. - For the linear losses, these loss contributions approximately compensate each other. - The Electrical shading losses are only related to the beam, and are therefore enhanced. In the same way, we have also a transfer of the IAM losses on diffuse to IAM losses on beam component. NB: These improvements are not very important in usual systems with low plane tilt, and negligible in tracking systems. They become crucial in vertical bi-facial systems modelling, for the evaluation of the back side irradiance in sunny conditions. In this case the circumsolar contribution was previously included in the diffuse, and therefore highly contributed to the incident irradiance on the rear side (result of the transposition), which is obviously not correct. The circumsolar contribution is now blocked on the face opposite to the sun. With the new simulation, rotating the East-West bifacial vertical collectors by 180° gives quasi-identical results. This new treatment explains the differences in the simulations between V 6 and 7, concerning the contributions in the optical losses (shadings and IAM). You can get the previous results by changing the Circumsolar treatment mode. Activation of the Explicit treatment of circumsolar The new calculation method was already introduced in PVsyst V6.80, but it needed to be activated explicitly by the user. From PVsyst V7.0 onward it has become the default. You can choose this setting in the main menu "Settings > Preferences", page "Physical models". NewTransposition.png Explicit circumsolar in preferences

Right now it is not possible to do this in PVsyst. Since this is a very special case, there is no plan to implement this in the near future.

Bifacial PV cells are not manufactured in a completely symmetrical way. The doping, metallization and passivation/texturing is different for both sides. This leads to different optical and electrical properties for the two sides, and thus different response for similar irradiance and temperature conditions. This difference is expressed by the bifaciality factor, which is defined as the ratio between front and rear side response at same conditions. Typically, the bifaciality factor ranges between 70% and 95%.

This passage is obsolete. You can re-use batch parameter files within the same project. Selecting 'Existing files' gives a choice of batch parameter files that have been created within the project.

In the PVsyst versions 6.67 up to 6.70, thin film PV modules with custom values for the shunt resistance Rsh and the series resistance Rs were not always read properly in the database, causing these resistances to be set to default values. This can lead to different performance results in the simulation. In these cases, for a correct simulation, please use PVsyst versions up to 6.66, or PVsyst version 6.71 and higher. The concerned modules display different resistance values in the PAN file editor. To check if a given PV module is concerned or not, open the module definitions with the different PVsyst versions: The PVsyst versions with the erroneous behavior for these modules are : V6.67, V6.68, V6.68 and V6.70. An (incomplete) list of concerned modules is: FirstSolar CdTe modules Calyxo CdTe modules Masdar PV Gmbh uCSi-aSi modules Schueco aSi modules NexPower uCSi-aSi modules

In the PVsyst versions 6.67 up to 6.70, thin film PV modules with custom values for the shunt resistance Rsh and the series resistance Rs were not always read properly in the database, causing these resistances to be set to default values. This can lead to different performance results in the simulation. In these cases, for a correct simulation, please use PVsyst versions up to 6.66, or PVsyst version 6.71 and higher. The concerned modules display different resistance values in the PAN file editor. To check if a given PV module is concerned or not, open the module definitions with the different PVsyst versions: The PVsyst versions with the erroneous behavior for these modules are : V6.67, V6.68, V6.68 and V6.70. An (incomplete) list of concerned modules is: FirstSolar CdTe modules Calyxo CdTe modules Masdar PV Gmbh uCSi-aSi modules Schueco aSi modules NexPower uCSi-aSi modules V6.67 - V6.70 <= V6.66, >= V6.71

The difference you are observing could be caused by a number of strings that is no multiple of the number of MPPT inputs, or even not a multiple of the number of inverters. When doing a simulation with no multi-MPPT feature, PVsyst will just distribute equally the power of all strings on all inputs of the inverter. If the number of strings is not a multiple of the number of inverter inputs, you will get a fractional number of strings per input. This is a simplification, since in reality you cannot connect a fractional number of strings to one MPPT input, and the result will be an approximation in this sense. With multi-MPPT feature activated however, PVsyst will try to match an integer number of strings to each MPPT entry. By default, it is assumed that each MPPT input can handle the same fraction of the total inverter power. This can give raise to strongly overpowered MPPT inputs. There are inverters with multiple MPPT inputs, which can distribute the total nominal power in a non-equal way among the inputs. When there are different numbers of strings at each input, these inverters can make a better use of the total power limitation, by assigning more nominal power to the inputs with more (or longer) strings. To simulate this kind of inverters, PVsyst allows you to specify explicitly the power that each inverter input will handle. This is called 'Power sharing' in the system dialogue. You should only use this feature if you are sure that the inverter you are using is able to the different MPPT inputs with different nominal power. In such a case, to describe the system correctly in PVsyst, you need to create several sub-arrays, one for each type of input configuration. Different input configuration means that any of 'Mod. in series', 'Nb. strings' or the power share differs. After creating the sub-arrays, you can adjust the 'Power Sharing' that is accessible through the corresponding button in the 'system' dialogue. The smallest losses are obtained, if the Pnom ratio is the same for all inputs of an inverter. The overload losses will always be higher than in the simulation without multi-MPPT feature, which is a kind of 'theoretical limit' of perfectly balanced MPPT inputs.

The behavior you are observing might be linked to the flag that controls the mismatch calculation before each simulation. Before a calculation involving ageing, PVsyst will, by default, do a Monte-Carlo calculation of the mismatch factor due to ageing. This leads to slightly different results every time you perform a simulation. You can also force the program to keep the same mismatch factor for each simulation. In the 'Ageing' dialog you need to check 'Keeps calculated Mismatch values'. In this case the mismatch values are kept fixed (also written to file) and the simulation will give always the same results. Keeping mismatch values fixed.

Indeed the file selection has no effect, and no profile is being loaded. I corrected the error and in Version 6.6.1 it is fixed. This version is planned to be published beginning of the week of March 20, 2017.

Yes, in principle the two should yield identical results. I will check this and post a reply.

The wrong unit display has been fixed for PVsyst Version 6.60.

There is an error with the units display. Although the label reads MWh, the values are in GJ. There is a factor of 3.6 between the two (1MWh = 1MJ/s * 3600s = 1GJ * 3.6). I will fix the error and post from which version on the fix applies. A comment on the work-around proposed by nickSHIFT: You can also retrieve the results from the Optimization tool in Excel. They are stored as CSV files in the PVsyst workspace in the subdirectory 'UserOptimization'. The file names are constructed from Project name, Variant Id, Scan Name and a counter. In those files, the energies are given correctly in kWh.

In PVsyst Versions up to 6.52, when a System is defined with PV modules of Jinkosolar together with Maxim optimizers, the default value for the 'Module Quality Loss' becomes 3%. This value differs from the case where the same modules are used without Maxim optimizers. In this case the default 'Module Quality loss' is 0.8%. The discrepancy is due to the fact that, by mistake, in the PVsyst Database, the Jinkosolar PV modules for Maxim optimizers, were not assigned a lower Tolerance for Pnom. The correct value of the lower tolerance should be zero, as for the modules without Maxim optimizers. The definition of the Jinkosolar Maxim modules will be corrected in PVsyst V6.53. Until then, the following approach will correct the problem: Correct the PAN file by opening it, and writing the value 0 in the field 'Tol. -'. Save under a new file name and use this new PAN file for the simulation. Once the PVsyst database has been corrected, these PAN files can be discarded.

The bug has been fixed for PVsyst V6.42, to be released in the coming days.

When doing the calculation according to strings, there is indeed a bug in V6.40 and V6.41, causing some of the shaded areas to be counted twice, resulting in too large electrical shading factors. The fix is being worked on.

In fact the variants were not being properly restored after each batch run step. This is now fixed for the coming version 6.42. Thank you for reporting the issue.

The electrical loss according to strings depends strongly on the specific details of the simulation. Could you send your project (or a minimal example where you observe the behavior) to support@pvsyst.com, so we can have a look at it? We did not introduce any fundamental change in this calculation, so we do not expect major differences in the results of V6.39 and 6.40.