Michele Oliosi

Please read https://www.pvsyst.com/help/bifacial-conditions.htm Your average tilt is likely too high for an accurate backside irradiance evaluation. You can change an advanced parameter (Main window > Settings > Edit advanced parmeters) to proceed anyway.

Hi, Indeed I think your supposition is correct, i.e. PVsyst does not recognize well the power sharing relating to this error message. We need to correct this bug. Note however that you can modify the inverter to disregard this error message: PVsyst will handle the simulation alright. The error you obtain is just a message telling you that the contractual conditions are not satisfied, it doesn't affect the simulation.

HI ! The tables seem too small for the module size. If you see the text in bordeaux red, you can see that the tables are 2.26 m by 1.13 m while modules are 2.278 m by 1.134.

Please read https://www.pvsyst.com/help/bifacial-conditions.htm This is likely due to your average axis tilt being too large to guarantee a very acccurate modelling of the backside irradiance. You can change an advanced parameter to pursue the simulation nonetheless, as explained in the help page above.

At the moment PVsyst will allow to work in "bifacial mode" only when there is a single orientation. There is no way around it at the moment. The best, if you can, is to split your system into several sub-systems (different variants) that have only a single well defined average orientation (if the topography is too complex, you can use the tolerance). Now for domes it is difficult to split the system into two separate orientations (because usually they are connected to the same inverter) and averaging the orientation is usually not very realistic. However for domes, since not much light arrives on the backside of modules, I think you can approximate the situation by staying monofacial, i.e. not activating a bifacial model.

IAM losses and transposition: Yes, the average is used. Until now, trackers always have a single average orientation. I assume you are talking about the backtracking strategy. In this case, yes the same pitch and width information is given to all trackers in the scene. There is only a parameter which is defined for each tracker independently, the axis tilt. Trackers with different axis tilts will move a bit differently under backtracking. Regarding the pitch and width, they are defined in Tools > Backtracking managament. In fact the "up to 8 orientations" is only the maximum limit for fixed tilt orientations. It is not related to the shading scene nor to trackers. In all cases, the shadings are computing taking the full complexity of the shading scene into account, including the topography. Basically yes, the calculation of the backside irradiance uses an idealized flat and regular model of the tracker positions.

The above information only concerns version 6. Versions 7 and above work along a novel premise altogether. The parameters "Threshold shading factor from.. " do not exist anymore.

To my understanding, the diffuse acceptance is for a point: The diffuse fraction on ground is what you get once you integrate all points of the ground.

In PVsyst, the diffuse component is considered isotropic. Therefore, it is sufficient to know for every point on the ground what portion of the sky (top hemisphere) isn't covered by other tables. This can be integrated for all positions on the ground. This fraction is purely geometrical, and is then to be applied to the total diffuse irradiance.

The following parameters : Axis azimuth / Phi min / Phi max / Uses backtracking / Pitch / Shed total width, in the bifacial window do not affect the simulation in any way. They are in this window for educational and studies purposes only. (See the text in dark red at the top of the window). The default values taken for the simulation (e.g. 44°) are taken directly from the 3D scene, if it exists, or the orientations window whenever you are using an "unlimited" orientation. My first guess is that 44° is the effective axis azimuth once you take all the trackers in your scene into account. Do you happen to have different patches of trackers with different azimuth? The value 44° should correspond to the axis azimuth value found in the orientation window. Could you check that they match ? Thank you for the suggestion, it could be a nice addition. At the moment we only work with the axis height above ground, because that would be specified once you choose a specific tracker model.

Hi this peak is due to the clipping, indeed any power above the grid limitation or inverter nominal power will be clipped to the value, the generation distribution is therefore biased towards values close to the clipping value. There is therefore probably nothing wrong with your system. However at the moment the scaling of the plots is automatic in PVsyst, and there seems to be a bug on that level. At the moment there is nothing that can be done to change the scale of plots when printed in the report, unfortunately. We'll be looking into how to improve this situation...

Should be out in the next patch ?

Hi, While the injected current is not an output in PVsyst, given E_Grid and the specific HV voltage, you can easily calculate the average current during each simulation hour. Just use the Advanced simulation > Output file tool to output E_Grid for each hour as a csv.

Did you have any unavailability time periods affected in the detailed losses parameters ? This may be the reason for this.

No in principle the total inverter power is maintained.

If you consider the "usual" sun path at equator, basically the sun will rise quite to the east and go up in the sky quickly and then go down to the west. The time spent by the sun around azimuth 0 or -180 is really shortened, with respect to a sun path at higher latitudes, with the sun being lower on the horizon. Essentially you want to maximize the time your sun is facing the modules, i.e. the azimuth and sun height match the plane orientation. If you are close to the equator, and your POA is north / south or south oriented, the time spent with matching azimuth will be quite low. However with a POA facing east or west the azimuth will match quite well for about half the day.

The view factor is calculated with the following idea: given a point on the ground, what is the part of the top hemisphere that corresponds to the back side of the modules. Indeed some of the light reemitted reflected by the ground will go towards the sky, other towards the structure, maybe some shading objects etc. With the view factor we are interested what is the proportion of reemitted light that actually goes to the back of the modules and not to some other direction. Now, imagine that the size of the tables with modules varies. Depending on the size and spacing of the tables, for a given point of reemission on the ground, the fraction of light rays that reaches the back of the modules will vary. In short, the point on the ground may "see" more or less of the back of the modules.

Hi @Ronald you can export a CSV file via the project window > Advanced simulation > Output file and then re-running the simulation from the Advanced simulation window. See https://www.pvsyst.com/help/output_file.htm for more details.

Hi @NoamD, Thank you for the feedback. In this case, I see that the simulation version is 7.2.3. There have been many corrective patches since then, so I would strongly suggest you update to the latest version, or at least to the latest version 7.2, i.e. 7.2.21. This will allow you to obtain more accurate results, and I believe this specific warning message should be resolved.

Thanks @kjs55 indeed that makes more sense. @MarVF6 indeed at the moment there is no native way to modify several orientations through the batch mode. In the medium long term we should be able to develop the feature along this direction, but to my knowledge it will take some time.

@Haus Yes I believe it is due to this new calculation. The overhead poles and wires probably cause very little shadings overall. Some of these situations were neglected in version 7.2.21, and are not neglected in version 7.3.2 anymore. I would suggest trying to change the advanced parameter controllling the cell width to 0, as in the screenshot above, and then making sure that the thin shading fraction is low enough. However depending on the original amount of shadings I believe the electrical shadings may increase even more. If you can let us know the results that would be very valuable. If the discrepancies are too high, I would invite you to send us your project at support@pvsyst.com (exported via the main window > File > Export project), this is the best way for us to check in details on a case by case basis.

In the system window, if you activate the "multi-MPPT" mode, you will be choosing a number of MPPT inputs for a given sub-array. In PVsyst, it is common practice to group MPPT inputs (or inverters when disabling "multi-MPPT") that share the same properties into a sub-array. You can create a sub-array with one or several MPPTs that will receive strings with the same shading situation, for example to prevent mismatch. If you do so, when you are using the module layout, you should be able to assign the corresponding modules to that specific sub-array. In the system window, do not forget to implement the "power sharing" between sub-arrays that belong to the same inverter configurations.

Hi you can have a look at https://www.pvsyst.com/help/ageing_general.htm The STC maximum power point average degradation will be the same no matter the modules, if the ageing rate is the same (%/year). However, since different modules have different one diode model parameters, the same ageing rate may lead to different behaviours for conditions such as temperature behaviour or low-irradiance behaviour. Then, if the plant has the same string layout, the mismatch degradation calculation will lead to the same mismatch due to the degradation (another loss that is due to ageing). But different stringing may lead to differences in the mismatch.

Hi Laura, Thanks for the feedback, we'll be looking into the issue, it was not a bug known to us yet.

Hi this tool uses monte carlo for the evaluation. Basically random trials are done every time. The values will only converge with many trials.