Search the Community

Optimizers Release note : Optimizer efficiency is now applied after module related losses The operating point at the optimizers input was previously computed before some losses that were purely module related. With this correction, all the usual array losses (except for the ohmic losses) are now applied before the optimizer. It may slightly change the input voltage, current and power, leading to a different optimizer efficiency and/or clipping losses. It will also be visible on the loss diagram, with the optimizer related losses now applied just before the ohmic losses. Release note : Optimizer: Power clipping is now better handled. When the optimizer(s) operating point at MPP is outside its nominal current or power, it must be shifted along the input IV curve. Before PVsyst 8.0.15, this shift was simplistic. For an overpower situation, the new power was set to nominal optimizer power, the voltage stayed the same and the current was reduced accordingly. A similar method was used for an overcurrent situation. For small overpower or overcurrent, the operating point shift is small enough that most collateral effect can be neglected. But for larger values, it may lead to unrealistic operating points at module and inverter level. The new algorithm is now similar to what is done with inverters. When clipping occurs, a new module operating point is selected on the IV curve, and the subsequent losses are recomputed. The consequences for most systems should remain small, but it will impact most projects using optimizers. Release note : Optimizers, SolarEdge: it is now possible to define subarrays with heterogeneous strings. When designing a subarray with SolarEdge optimizers, it is possible to have a string of optimizers in which all but one of them are connected to 2 modules. This so-called "heterogeneous string" is now possible to model in PVsyst. In a subarray with SolarEdge optimizers, if there are exactly two modules in series at the optimizer input, a checkbox will appear: When checked, the last optimizer of the string will be set with only one module, while all the other ones will have 2. In this example, one can see that there are 6 optimizers in series, for a total of 11 modules per string. Storage Release note : Grid storage: revision of battery operation calculations The battery control strategy has been reworked, leading to a more accurate implementation of the deratings at low and high SOC. This update may impact projects using a battery that often reaches its min or maximal SOC. Shadings Release note : 3D scene: small width changes in PV table dimensions (<3cm) now modify the total sensitive width/height The PV table dimensions (PV module + inter-module spacing + inactive band) were saved individually in the 3D scene, however small changes in the different components (below 3cm) did not trigger the computation of the total combined width or length. When opening old projects affected by this bug, the total "sensitive" width/length of PV tables will be recomputed. This can have a small impact on the shading computation. Release note : Trackers, diffuse shadings: "central tracker" and "custom tracker" modes now offer the choice of including shading objects in the calculation For trackers, diffuse shadings can be sped up by computing shadings only on a single (representative) tracker. The options "central tracker" and "custom tracker", which implement this choice, can be selected in the 3D scene > Tools > Trackers diffuse shadings definition window. In these two cases, shading masks (i.e., objects that cast shadows on the representative tracker) are selected by PVsyst. Up to version 8.0.14, only neighbouring trackers with the same orientation could act as shading masks. From version 8.0.15, by default, shading objects in the scene are also used as shading masks. A checkbox permits the exclusion of shading objects, effectively reverting to how 8.0.14 functioned. This choice is written in the simulation report. More information on this feature will be available on the help page https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html

Two corrections impacting electrical shading results Release note: Shadings: the bottom cell size is now taken into account also when computing the shading factor table from the Near shadings window. Between versions 8.0.0 and 8.0.11, the bottom cell width was not available in the Near shadings window calculations. Therefore, recomputing the shading factor tables by clicking the “Recompute” button, or computing the tables when prompted when closing the Near shadings window could lead to slightly incorrect results, especially for low sun heights. Version 8.0.13 corrects this bug. Shading factor table calculations will be consistent no matter where they were called from. If you were using the "according to module strings" model in "Fast", it is possible that electrical shadings will slightly increase due to this correction. Release note: Shadings, thin objects: the partition model results in presence of thin objects have been corrected. This may impact the simulation results, by increasing the electrical shadings slightly in some cases. In previous patches of PVsyst 8, the electrical shading factor in the presence of thin objects, when using the fast simulation mode (table interpolation), was not calculated correctly. This could lead to an underestimate of electrical shading losses. Note that this bug was not present in version 7. Moreover (also in previous PVsyst versions), whenever the total irradiance loss was lower than the electrical shading loss from normal objects (case with many thin objects), the electrical shading loss could also be underestimated. Although very rare, this case is now corrected as well. Improvements of the bifacial view factor model Release note: Bifacial: corrected calculation of the sky diffuse contribution on the rear side of the PV modules This patch addresses several issues in the modeling of the sky diffuse on the rear side. The impact of the number of rows has been reassessed; it now better captures the fact that the rows at the extreme end of the array do not experience mutual shadings, for all diffuse components. The rear side diffuse view factor has been revised; a normalization factor now correctly depends on the tilt. A discretization effect that caused an East-West asymmetry for trackers has been fixed. These issues were most impactful in the following two cases: systems with vertical tables, and systems with few rows of tables. With this correction, the modeling of irradiance on the front and on the rear have been harmonized and generally have a better match. However, the impact on the total system output remains small, amounting to less than 0.5% for most bifacial systems. Note: Systems with a single table, or a single row of tables, can currently only be designed with “unlimited” orientations. A workaround duplicate all the elements in your 3D scene and place it sufficiently far away so that mutual shading effects are negligible. Considering the power factor in the System window for sizing assistance Release note: System design: Overload losses are now adjusted when a Power Factor is specified in “Energy Management”. When requesting an inverter to produce reactive power, its overload conditions may be impacted. This will depend on its nominal power specifications. If the nominal power (PNom) is specified as apparent power ([kVA]), a power limitation will apply in terms of active power according to the formula: PNom(active) [kW] = PNom(apparent) [kVA] × cos(φ). Since PNom(active) is lower than PNom(apparent), overload losses increase and depend on the chosen power factor (cos(φ)). Once a yearly power factor is specified, the estimation of overload losses in both the System and Sizing windows will take this effect into account, indicated as “Overload loss, with PF”. This estimation now more closely reflects the values shown in the loss diagram. Future versions will include the estimation of overload losses for monthly power factor as well. A more detailed explanation is available in the Help section: https://www.pvsyst.com/help/project-design/grid-connected-system-definition/power-factor/index.html Warning message “inverter is slightly/strongly undersized” Release note: System Sizing: warning and error messages for inverter slightly and strongly undersized are now triggered at 2% and 4% overload losses, respectively. These errors are not fatal anymore. In addition to the previous point (considering the power factor in the System window), the fatal error message “the inverter is strongly undersized” is no longer triggered at 3% overload loss. Instead, it is now issued as a warning that does not block the simulation. For new projects, the threshold for displaying this message has been updated to 4%, acknowledging that moderate inverter overloading has become a common practice. For older projects, the threshold is still set at 3%, which can be modified in the parameters of the project.

This post aims to present the main differences a user can encounter when using PVsyst 8.0.12 compared to PVsyst 8.0.11, including PVsystCLI. New functionalities for PVsyst CLI Three new parameters have been added to the run-simulation command: --batch-params-file (-bpf) --batch-rvt-file (-brf) --recompute-shadingfactors-tables (-rst) The two first will allow running a batch of simulations from CLI, thus enabling automatized parametric studies. An example use case has been added to the page https://www.pvsyst.com/help-cli/use-cases/simulation.html The third option allows choosing whether shading factor tables should be recomputed at the beginning of the simulation. More information on the commands and their usage can be found at https://www.pvsyst.com/help-cli/reference/index.html Correction impacting the modeling of optimizers Release note: Optimizers: Minor update of the optimizers MPP choice under partial shadings with module layout shading model When using the “module layout” shadings model, the MPP tracking algorithm now works better during partial shading conditions. In previous versions, it used to select an MPP at low voltage output, sometimes leading to inverter minimum voltage related losses. This correction may lead to a slight production increase, mostly from a reduction of inverter voltage threshold losses. Other minor corrections in the context of the modeling of optimizers concern Huawei optimizers : Correction of the efficiency computation, leading to a slight increase of the optimizer efficiency losses. With long strings (i.e., when the string voltage at STC is higher than the inverter MPP input maximum voltage), the individual optimizers' operating point selection now takes into account the minimum inverter input voltage. Under low-light conditions, this may improve the inverter efficiency by selecting a higher voltage operating point. Updated Bifacial PR The bifacial PR is now available in the report and in the monthly result tables. Its abbreviation is “PRBifi”. Note that the definition was also updated to now take into account the bifaciality factor. For more information, please check https://www.pvsyst.com/help/project-design/results/performance-ratio-pr.html

This post aims to present the main differences an user can encounter when using PVsyst 8.0.7 compared to PVsyst 8.0.6. Thin objects In versions 8.0.0 to 8.0.6, PVsyst did not calculate correctly the electrical shading losses for thin objects. This problem could be identified by inspecting the shading factor tables, showing inconsistent values when selecting “Thin objects table”: The calculation in PVsyst 8.0.7 now takes these properly into account. Electrical shading losses may be modified in your projects with thin objects because of this. Bifacial systems Several changes will affect projects with bifacial modules. No fundamental changes were made to the model, but default values and parameter labels have been updated. PVsyst 8.0.0 introduced the possibility of defining the number of rows and pitch used in the backside geometry model manually. Previous to that, the number of rows and pitch were automatically extracted from the orientation definitions, or from the 3D scene when available. This automatic evaluation was not always correct. For unlimited orientations, the number of rows used in the bifacial model is now forced equal to the number of rows in the orientation menu. Related fields in the bifacial menu cannot be edited anymore. See below in 'New Warning' for the behavior when opening a variant with simulation results that were using a user choice for the number of rows. Default number of rows The estimate for the number of rows has been improved. For example, in version 8.0.6, the number of rows returned the total number of trackers. This is now fixed. Note that with complex 3D layouts, this estimation could still be not fully representative of your system. This is why it is possible to override the number of rows manually. Reading PVsyst 7 or earlier simulation results Variants stemming from PVsyst 7 or earlier did not store the number of rows parameter. When reading the results in PVsyst 8.0.7, for variants where the number of rows cannot be determined retroactively, the report will show an “NA” note for the number of rows. If a new simulation is run, the number of rows will be set to the new default value. New warning A warning will be displayed when the user sets a non-default value for the number of rows in the backside geometry model. The PVsyst estimation for the number of rows is based on the 3D scene layout when available. With complex 3D layouts, this estimation could be not fully representative of your system. In such a case, this warning can be ignored. For the rare cases, where a variant with an unlimited orientation contained a user choice for the number of rows in the bifacial model, this warning will also appear if the variant contains simulation results, to make sure that the report and results correctly reflect the settings that have been used for the simulation. Since this option is not available anymore in V8.0.7, it is not possible to change the number of rows in the bifacial window. However, when running the simulation again with V8.0.7 the number of rows will toggle back to the default value, which is the number of rows defined in 'Orientation'. EW axis and NS-frame trackers When the azimuth of the axis was not zero, shadings were not properly calculated. This meant that the “Near shading losses” were not reliable. This has been corrected. Grid limitation and trackers In versions 8.0.0 to 8.0.6, a bug when combining grid limitation and the tracking algorithms “irradiance optimization”, “wind stow” or "seasonal tilt" prevented these algorithms from being properly applied. This has now been fixed. This may increase transposition gains in your variants, as irradiance optimization now corrects the tracker motion to maximize irradiance properly.