Michele Oliosi

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.

Hi thanks for the suggestion, it makes sense. We will consider this as a possible improvement of the report. One worry might be users thinking that this new percentage IS the bifacial gain.. this is not what we want of course. But we can try to use a very clear denomination.

@vishnu Short answer: No, for system modellings it is best to stick with the simpler model used by PVsyst. Monofacial modules also receive irradiance on the backside, the only thing that changes is the PV conversion on the backside, which won't have a big impact. Longer answer: I understand that you want to include the backside irradiance as a contribution, but this contribution already exists in the case for monofacial modules. Therefore what you suggest is a new general model that should be be applied also for monofacial modules (they alse receive light on the backside). On top of the above, the model you suggest needs several tweaks. Most importantly the irradiance on the backside is not simply ???∗??????∗??????????? ??????. It is the result of the geometric model that takes into account both reflection on the ground and direct sunlight on the backside. This should be replaced by the PVsyst variable GlobBak. Also, the bifaciality factor modifies the efficiency ????. Finally, the absorption coefficient ? should affect also the backside part. So here is a new suggestion: Tc=??+((????∗?)∗(?−????)+(GlobBak∗?)∗(?−????∗??????????? ??????))/(?'?+(?'?∗??)) However, in this new formula U'c and U'v are not the ones used in the "monofacial" formula hence the primes. One should make one or rather several studies to find these values. Until this kind of model is not backed by a good corpus of literature and accurate measurements leading to the new U'c and U'v values, it is definitely best to stick with the simpler, partially validated, model. As mentioned above, even for non-bifacial modules, there will be irradiance on the backside, i.e. the original values Uc and Uv already took into account this contribution. There is no compelling reason to adapt it in PVsyst on ground of using bifacial models.

Hi bendesa1962, Your understanding and definitions are correct. However your example is incorrect. In the southern hemisphere it will be: Facing North is 0 Facing South is 180 Facing East is -90 Facing West is 90

Indeed this fix has been (long) forgotten, thank you for the reminder. It should be implemented in version 7.2.10.

The global fraction on ground, that you find in Bifacial system > Unlimited Trackers 2D model, is calculated for clear sky conditions. As such, it is not applicable to your simulation results (unless you have a clear sky meteo file). Your intuition about how the global incident on ground is calculated is correct. However, PVsyst does the calculation hour by hour and differentiates the beam and diffuse irradiance components. The beam and diffuse components have different "fractions on ground", that will generally vary every hour with the sun / tracker positions. Therefore it is difficult (probably even impossible) to calculate it from the current outputs of PVsyst, in particular from the monthly results.