Michele Oliosi

The shed to shed slope, is the slope in the front-back direction of your tables, usually NS direction. Your tables therefore all have the same orientation (tilt and azimuth) but are at different heights due to the slope. In the case of the baseline slope, we consider a slope along the bottom of the table, usually EW direction. Your tables effective orientation will be changed, since the orthogonal vector to your table surface does not correspond to the original nominal tilt and azimuth.

PVsyst does this rather intuitively. You can either consider the inverter as a whole and let PVsyst balance strings on inputs (good for balanced strings), or consider MPPT inputs individually. In the most simple case, for balanced strings, and if you are filling all MPPT inputs with 2 strings, you don't have to do anything special. You can uncheck the "Use multi-MPPT feature" checkbox to consider the inverter as a whole. For a more complex case, you should use the "Use Multi-MPPT feature" checkbox. In this case, for a given sub-array, you will consider single, or groups of, MPPT inputs and associate a number of strings to them. In each of these groups the strings are shared in a balanced way. In this latter example there are two strings on a single MPPT input.

Yes the latest version of PVsyst (7.2.12 at the time of this post)still assumes horizontality for the bifacial model. As long as you don't modify the parameter too far from the original 2° (it is an order of magnitude estimate, not a hard limit), the error should be minimal

As mentioned in the messages in red, the axis tilt needs to be horizontal or nearly horizontal to use the bifacial model. In your scene the average tilt is apparently 2.4°. The default limit in PVsyst is 2°. You can relax this requirement at Home window > Settings > Edit advanced parameters, but at your own risk ! Indeed, the bifacial model will anyway assume horizontal axis, so there will be a discrepancy (in the backside contribution) with the reality of your scene. This may cause some inaccuracies in the backside contribution.

Hi, Yes unfortunately at the moment it is not possible to use the bifacial model with several orientations. One way would be to do as you write i.e. split the system in two and join both results. However, this will likely overestimate the backside production : e.g. the East tables will cause shadings that impact the backface of the West tables, and vice versa. These won't be taken into account when proceeding in this way.

The thin object shading percentage is a modifier to the electrical shading factor generated by thin objects. Basically if thin objects cause a near shading factor F, the simulation will instead use 40% of F in the simulation (just as what happens with the global "Fraction for electrical effect). Once you define at least one thin object, you will be able to adapt both the main "Fraction for electrical effect" which is applied to all objects except thin objects, and the one for thin objects that is applied to the factor caused by thin objects only.

Hi, This will be taken into account in a future version, although not sure which. Most probably this will be added to a major version. I agree that it makes more physical sense. Thanks for the feedback !

Keeping a given ground surface area constant and filling the area with modules according to pitch and tilt needs is a more complex task than the optimization plots already available, and this is not available as a tool in PVsyst yet. You could use the batch mode for this. In the case of a PV array, it is possible to modify the number of rows, as well as pitch, tilt, and other parameters. One should then calculate, in order to prepare the batch file parameters, the corresponding number of rows for a given pitch. This is not implemented as an automatic function in PVsyst. Note that the batch mode can output several variables as a csv, so the analysis of the results on excel would be quite simple. I can see how this could be a cumbersome task. We will add a ticket to possibly offer this as a tool directly, and potentially simplify this procedure.

Hi In the shading scene, you can access Tools > Orientation management. There you should be able to manage the average orientations, by changing the tolerance. Alternatively you can also create the three orientations (in the "Orientation" window) before importing the scene. You should then be able to assign the fields using the tool above.

Dear allanfisica, You are right, there is a mistake in the help, we will update the values. Thank you very much for the feedback. This also allowed us to find a different bug in the software that alters the value of the temperature corrected PR by a tiny amount (typically ~ 0.001). We will correct this in an upcoming patch.

Hi, Actually one of the default outputs from the simulation is almost what you need. Since bin is the accumulated irradiance, you can simply divide by the bin irradiance (the x value) to obtain the number of accumulated hours. You can access the values by clicking on "Detailed results" > "Predefined graphs" choosing the right graph and then exporting the values. You can also directly obtain an hours accumulation from the "Meteo Tables and Graphs" window, accessed when viewing a meteo file in the database, or from the project. Hope this helps !

Hi ! If you have a specific project or reports, with two variants showing the differences, you can send them at support@pvsyst.com You can export a project via the main window : File > Export projects

The time of your lower screenshot is 16:15, while your 3D scene seems to have time around 2-3 pm. Please use this tool to set the right time in the 3D scene. Once the time is set, click on "apply". Please let us know if this improves the situation.

From what you say about the system, especially it being an east west dome system it is likely that the bifacial gain will be low. However someone with more field experience should formulate a better answer here. From the PVsyst side it is as you say: the bifacial model and hence the backside irradiance do not take into account the shading scene for the shadings, only the interrow spacing, size of the tables, and the orientation are used. Therefore 5% is likely an overestimation.

A disclaimer: my answer is just based on physical intuition, not on a specific study. Because of the mesh thickness it could be a bit worse than that for diffuse light. If you want to be on the safe side you can increase that factor. However the best course of action is probably to make some measurements on a test module to ascertain these losses.

This is one of the default plots. Once you have simulated your variant, you can choose this plot in the drop down menu. Incident irradiance histogram

Sorry there is no workaround in this case. This is especially the case with solar edge components, which have strict functioning rules.

Hi, The "[...]BatchParams[...].CSV" file is not the simulation output, but will contain the parameters to be varied and the different simulation runs. As such it is a very small file. You have to fill it with the values for the variables to be varied. Once you then press simulation (in the advanced simulation window) the batch run will commence. At the end you will have a file named "[...]BatchResults[...].CSV" You can also send us the file at support@pvsyst.com, if you think the file is wrong.

The NS pitch is the separation between the bottom of a row to the next bottom of row. I.e. it is really equivalent to the row spacing.

No it doesn't calculate this automatically. There are however some quantities and graphs that can give you some indications. For example, if you are not using a 3D scene, you can use the "unlimited sheds" orientation. In this case, you can, from the orientation window read the shading limit angle (above which there will be no shadows on your system), and display the shadings graph, which overlaps the shading angles with the sun path. To position the tables, either you can use the above unlimited sheds orientation, or you can do that "manually" in the 3D CAD editor in "Near shadings".

Thank you for the feedback on the naming of the variables. The issue has been raised and we will try and clarify that in one of the next updates.

@dtarin yes indeed, the norm IEC 61724-1:2021 https://webstore.iec.ch/publication/65561 explains how to compute a "bifacial" PR. This is however not included in the results of PVsyst yet, so at the moment you have to do the calculation by yourself.

Hi, The bifacial model only considers mutual shadings due to the geometric arrangement of the PV tables, and not the shadings extracted from the 3D scene. The 3D scene only affects the front side. This is due to the analytic nature of the bifacial model, that works under the assumption of regular rows of tables or trackers. The performance ratio used by PVsyst is the standard one, i.e. normalized to the frontside POA irradiance, please see https://www.pvsyst.com/help/performance_ratio.htm for its definition. This is why it can be above 100% for bifacial systems.

Thank you for the feedback on this tool. We will take this kind of comments into account for a future overhaul. The reason for this graphical representation is that the "handle" on the rotation angle is the "lever" with the red point, below the tracker table. If you move the lever around the limits should become quite intuitive.

Hi, I am not able to reproduce the error with a simple case so I assume you have a complex shading scene here. Maybe you can have a look at the window "Tools" > "Backtracking management". You should be able to see which value for the pitch is chosen. Else can you send us your project at support@pvsyst.com? (Main window > File > Export projects) It will make it much faster for us to figure out what is going on.