Bruno Wittmer

The screen shot from the module layout window does not correspond to the situation on the first screen shot of the 3D editor. You have to set the date and time to the same hour in order to get the corresponding calculations. Please check for which timestamp exactly you get the conditions of the first image, and then set the date and time accordingly in the module layout window. The results in the screen shot of the module layout window seen consistent. The two strings are clearly on separate MPPT inputs, and both strings are partially shaded.

This level of detail is not yet covered in PVsyst. There is only one albedo value to describe the ground properties. Furthermore, the current bifacial view factor models are based on a cross section of the table rows, and don't allow to describe changes of properties along the row. In future PVsyst versions there will be a bifacial model based on the 3D drawing, which might allow the introduction of such varying ground properties. As of the date of this post, there is no timeline yet for when this will be available.

The calculation of the maximum expected voltage at the inverter input is a safety issue, meaning that a single event might already cause damage to the equipment. Therefore, it is necessary to check the worst case scenario for the question:'For my PV system, which is the lowest possible cell temperature with some significant amount of irradiance at the same time?' As your plot nicely shows, the Voc curve is quite flat from 300 W/m2 onward, meaning that already rather low irradiance brings you close to the maximal voltages. If you think of the worst case scenario, there are two points that are not taken into consideration in your argument: It is not advisable to look for the worst case in the meteo data of a typical year, since it is quite likely that the worst case happens rather in an exceptional year. If you would like to take the worst case from measured data instead, you should probably look at decades of measurements, in order to be sure to find a situation coming close to the worst possible case. In any case, I think it is better to just estimate the worst possible conditions, and work with generous safety margins. The worst case scenario is not a stationary situation, where the PV modules are in thermal equilibrium with the surroundings. I think the worst case is on a cold day, when the PV modules are roughly at ambient temperature, because there are many clouds and very little irradiance. If then the clouds open quickly enough, such that the PV modules do not have time to heat up, you will get the highest possible values for the PV module voltages. Please note also, that the calculation uses Voc, which is higher than the normal operating voltage Vmpp. Also here, the idea is to consider the worst case, and not a standard situation. As you can see, the reasoning here is to completely exclude the possibility of the voltages at the inverter input exceeding the safety threshold. For this purpose, we consider it to be reasonable to constrain the lowest possible cell temperature to values of 30°C or lower. If however you think this is too limiting for your simulation, you can still increase the maximum voltages in the OND and PAN files, but be aware that you are working very close to real safety limitations.

If you choose "account as separate loss" for the grid limitation clipping, the simulation itself will not change. Apart from some possible small rounding errors, you should get exactly the same results for the generated energy. The only difference is that the inverter power clipping losses, which were found in the simulation variable IL_Pmax, are now split in two variables: IL_Pmax and EGrdLim. IL_Pmax is the amount of clipping due to the power limitation of the inverter, while EGrdLim is the additional clipping imposed by the grid injection power limitation.

This is a matter of definition. 'Direct Use' in this context just means that the energy did not go through the battery. You can compute the energy that went directly from solar to self-consumption by subtracting E_Grid from this value.

The variable EDirUse containds already E_Grid. It represents all the energy that does not go through the storage: E_Avail = EDirUse + EBatCh

Dear Allison, Thank you for the clarification, I am now able to reproduce the behavior of point a). We will fix this for one of the next releases. We are sorry for the inconvenience, and thank you for reporting the issue.

These tables are indeed not correct. If you need these values, please use the hourly output file of the simulation to get hourly values, and perform the averaging outside PVsyst. We will fix this problem in one of our next releases. Thank you for reporting the issue.

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 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.