Michele Oliosi

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.

Unless you are in the ideal case, a pure backtracking on a hill is impossible. Please see: https://www.pvsyst.com/help/backtracking_onhill.htm Therefore PVsyst does not have any slope awareness in terms of backtracking. The backtracking algorithm is a usual one, i.e. adapted to flat ground and regular rows of trackers. The only parameter that is considered by PVsyst is the horizontal pitch between trackers (and tracker sizes of course) so that the elevation difference will play no role there. Therefore, with a constant slope or complex topography, you will have a sub-optimal orientation of your trackers, oftentimes leading to mutual shadings. This is realistic, unless you have a special slope-aware algorithm. (To our knowledge, constant slope situations do not really happen in reality ?) Finally, note that PR is not an intuitive measure to compare backtracking with no backtracking, because the normalisation is on the POA irradiance, which is reduced in the case of backtracking (leading to a higher PR). Please see https://www.pvsyst.com/help/performance_ratio.htm

If your shading scene is regular enough you can still use it alongside the "Fixed plane" orientation and use the bifacial model as well. In the current version (7.2.11) I haven't been able to reproduce the issue you describe. If you keep experiencing this bug please send us an email with your project or more information.

No updates yet, your procedure is still the best way to proceed. Development is underway but there are other features that have higher priority.

Sorry for the very late reply. You can find some info on our help page, e.g. https://www.pvsyst.com/help/bifacial_procedure.htm. Feel free to drop us a support email if you have more trouble.

Sorry for the late answer. In few cases an error in the calculation for the projection was leading to negative backside irradiances. Note that there have beeen many bugfixes on tracking / bifacial systems over the first few patches of version 7.2, so please always update the software to the latest patch.

It still depends on the scene. PVsyst lets you use the bifacial model with a 3D scene in two main cases: - fixed planes - horizontal NS-axis trackers Note that the 3D scene must always be regular, in terms of pitch, table geometry and orientations. If for example the topography is too complex, PVsyst may not let you proceed.

@tecnum There are actually breaks in the slope every 5 years, only two of them are more extreme than the others. This is due to the mismatch values that are generated by Monte-Carlo (you see them given for every 5 years). This degradation is “random” in nature, so some erraticism is to be expected. The current code’s philosophy is that since this is a random model, that does not reflect “real values” for which we have good time series (unlike weather for which the statistics can be known over many years), there won't be much to gain in having a more fine-grained approach.

Sorry it's not possible at the moment to have different power factors between inverter and injection point. You should just use the grid injection point one.