Michele Oliosi

Hi, Thanks for reaching out on the forum. The main difficulty is that front side and backside are modeled differently in PVsyst. Starting with the shadings in the iso-shadings diagram, these shading factors are only applied to the front side. This is why the shading just shows up on negative azimuth side, which must be the front side in your case. The backside shadings are applied differently: they are inherent to a view factor model. The back side is mainly modeled as defined in the System > Bifacial system window. There, you should activate a bifacial model, and make sure albedo coefficients are consistent with the front side ones (found in the project settings). The structure shading factor should be chosen as zero to match what happens on the front side (unless there is some component clutter in the backside, cables, combiner boxes, etc). Moreover, I'd recommend choosing a mismatch loss factor in the Bifacial system window equal to the front side's electrical shading loss. This latter factor will appear in the loss diagram if you choose a fitting model in Near shadings: either the partition model (according to module strings) or the module layout model (detailed electrical calculation).

Sub-hourly simulation Release note: Sub-hourly Simulation for Grid-Connected and Standalone systems The main feature of PVsyst 8.1 is the possibility to run sub-hourly simulations. It is therefore now possible to model a PV system with more accuracy. Several physical models have been adapted to this new time scale, as detailed in the next section. The granularity at which it is possible to simulate a project is directly that of the weather data file (.MET). To support this feature, it is therefore also possible in PVsyst 8.1 to import sub-hourly weather time series to generate sub-hourly weather data files. At this time, sub-hourly files can either be created by using the custom weather import or using the Meteonorm 9.0 DLL and choosing the `minute` option. All weather data files, independently of their time step, can also be used to run hourly simulations. A radio button, present both in the main project window as well as in the "Advanced simulation" window, allows you to easily switch from one granularity to the other. Sub-hourly simulations will correspondingly generate sub-hourly time series tables when using the "Output file" functionality. Hourly simulations retain the advantage of being much faster, since fewer steps need to be simulated. It is therefore recommended to run hourly simulations during iterative design phases. Sub-hourly simulations, which take longer to run, can be left for more final evaluations. Generally, small differences may appear between hourly and sub-hourly simulations. This is inevitable, since several physical models are nonlinear and are therefore sensitive to averaging in time. For the most part, sub-hourly models lead to small changes that can be considered small gains in accuracy. However, some models have required more work to ensure the accuracy of the simulation at all time scales (see section below) despite more important differences between hourly and sub-hourly calculations. Note also that the largest discrepancy, i.e., clipping effects, is still addressed in hourly simulations (since version 8.0) with underlying sub-hourly weather data with a dedicated correction. Improved physical models With the new possibility to run sub-hourly simulations, several models had to be adapted. The three main changes concern models that did not preserve sufficient accuracy when applied at sub-hourly scales. Release notes: Thermal model: PV module temperature is now computed using a transient thermal model for both hourly and sub-hourly simulations Weather data, custom file: new model to estimate diffuse horizontal irradiance from global horizontal irradiance. Dedicated coefficients for sub-hourly simulation are used in order to reduce the discrepancies with hourly simulations Transposition model: sub-hourly horizontal diffuse irradiance data with the Perez model now uses coefficients adapted to each time step. These adapted coefficients aim at reducing the discrepancies between sub-hourly and hourly simulations Each of these changes is detailed here below. Transposition model The default model used in PVsyst, the Perez model, relies on several weather data indicators (sky brightness, sky clearness, sun zenith angle), associated with a set of empirical coefficients, to decompose the horizontal diffuse irradiance into components that are to be transposed with different geometric rules. This decomposition leads to effective discrepancies when comparing corresponding hourly and sub-hourly time series. When studying an ensemble of sites across the globe, this granular discrepancy translates to a systematic discrepancy, averaging half a percent in terms of PV system yield. Since the empirical coefficients used in PVsyst (and in several other simulation software) have been fitted with hourly and quarter-hourly data, the sub-hourly results of the Perez diffuse decomposition using these coefficients can be considered biased. For this reason, a new set of coefficients, which corrects the bias observed over 113 sites worldwide, is used by PVsyst when running sub-hourly simulation with the Perez model. Note that the direct irradiance transposition also leads to discrepancies between hourly and sub-hourly simulations. While the exact cause is not yet understood, since the transformation is purely geometric, the sub-hourly simulation can be considered more accurate in this regard. Decomposition model When importing custom weather-data with only global horizontal or only plane-of-array irradiance, PVsyst must estimate the diffuse horizontal irradiance. This was done until now using Erbs model. This model, based on a single clearness indicator, is considered to have sufficient accuracy for hourly simulation. However, at shorter timescales, it fails to capture fast phenomena such as cloud enhancement and results in a systematic discrepancy compared to real measurements. To reduce this discrepancy, we selected a more flexible model from the literature, ENGERER2, whose additional indicators (clear-sky clearness, cloud-enhancement index, ...) allow one to represent sub-hourly dynamics more accurately. Similar to the adaptation of the Transposition model, we refitted the model coefficients to reduce the bias observed on the previously mentioned 113 sites dataset. Compared to Erbs, this new computation successfully mitigates the bias for all sub-hourly timescales. It also mitigates a small residual bias of the previous model at the hourly timescale. This small difference will slightly affect all irradiance loss components (IAM loss, shading losses, ...) affected by the decomposition of irradiance into components. Transient Thermal model In PVsyst 8.1, two layers of thermal models are used for the PV module: First, as in previous versions, the thermal balance model outputs the steady-state temperature, represented by the PVsyst variable TArrSS. Second, a thermal inertia model uses the previously calculated steady-state temperatures to compute the actual transient temperature, represented by the PVsyst variable TArray. The user can modify the heat transfer coefficients and the mass of the module (affecting the thermal inertia) in the detailed losses and .PAN file menus, respectively. For hourly simulations of conventional PV systems, thermal inertia affects the production E_Grid by about ~0.1-0.3% annually. In particular settings, it can have a stronger impact. For example, if an inverter is designed to operate close to its over-voltage limit, production can be affected by 1-3 % annually, as the temperature change induced by thermal inertia mainly impacts the PV array voltage. Optimizer current clipping Release notes: Optimizers: current clipping at optimizer level is now better handled In PVsyst 8.0.15, the physical model for optimizer clipping was improved (https://forum.pvsyst.com/topic/4586-pvsyst-8015-main-changes/#comment-13209) But when current clipping occurs (common with "long strings"), the computation was not correct and overestimated the need for clipping. This problem has been corrected in PVsyst 8.1.0, which may reduce the value of OP_Imax (optimizers current clipping losses) and increases EArray accordingly.

Sorry no news yet, we are looking at update 8.2 at the moment... but that could change still.

ReflBck = (GlobGnd - ReflLss) * GroundArea / ModuleArea - BkVFLss or ReflBck = (GlobGnd - ReflLss) / GCR - BkVFLss

Hi, The reason is that GlobGnd, DiffGnd and ReflLss are variables that refer to the m^2 of ground area. Whereas, BkVFLss refers to the m^2 of PV modules. If you were to mutiply by the respective surfaces (ground surface > module surface), the energy hierarchy would make sense.

Funny, I just added this in the help of our 8.1 candidate a few days ago. Hence sure, will be present in 8.1 🙂 Indeed, that is the correct citation.

Hi this is still not possible. It is still as @dtarin commented.

Hi, It's definitely possible. Currently the prerequisites for the EPI test are not very strict. It is about comparing total expected energies with measured ones, filtering for various contexts, with an hourly aggregation of measurements. PVsyst will generate a time series of results with various intermediate variables, that can help with filtering (e.g. for constrained periods). This time series can easily be compared with the measured one. For capacity testing (PPI), depending on the version of the standard -2, ed. 1 or 2, it is more or less easy to do. Ed. 1 should be straightforward. Ed. 2 has minute simulation as a prerequisite. Currently, PVsystCLI or PVsyst + batch can help implement a batch of 60 simulations (one for each minute in the hour) to mimic a minute-resolution simulation. This is a bit cumbersome, though. Luckily, we are working on PVsyst 8.1 which will simulate in minutes as well. The version is well underway (and the minute simulation is confirmed to work). This will make the ed. 2 capacity test straightforward as well.

You can find more information here: https://www.pvsyst.com/help/physical-models-used/pv-module-standard-one-diode-model/pvmodule-structure/bi-facial-modules.html

When using the optimization tool with a 3D scene, PVsyst will change the nominal tilt of each individual table in the 3D scene without changing the base slopes. If there are nominal tilt differences these will be lost. If there are base slope differences, these are kept, which may result in an effective average tilt different than the value you chose in the optimization tool.

Hi ! Currently that is difficult to do for each table. For zones, a workaround can be found. The idea is to use the "partial shadings caclulation group" concept (https://www.pvsyst.com/help/project-design/shadings/partial-shadings-and-calculations.html). You can put a zone in the group. Then run the simulation, and the shading loss factor will be computed on that group + any additional shading objects (not the other tables though unfortunately). For zones the approximation should be good. This can be done through the interface, and as long as there are not too many groups should be feasible by hand. I have been experimenting with a script and PVsystCLI to try to define the groups by modifying the variant file and running the simulation programmatically. While this is possible, it is rather convoluted. The caveat of the other tables not casting shadows remains though. I need to experiment a bit more to get a result table by table.

Right, this setting is not very realistic anyway, it creates very long trackers if I recall correctly.

Good to know it works ! Actually I was not sure if [X,X] worked, I seemed to remember that at some point in the past the trick did not work unless there was a difference between min and max.

Hi, this feature is in our roadmap, but not before a few patches after the release of 8.1.0 With our internal beta of 8.1.0 we could already mimic this by running a simulation, then using that to determine a grid limitation time series that truncates the inverter power with ramps, and then resimulating with this new grid limitation time series. In version 8.0 the workaround is a bit more convoluted. You could mimic this with a self-consumption profile that acts as a stand-in for the losses in ramp-up (you would also need to simulate, then post process, create the load profile, then simulate again), but that is less practical as a workaround.

The production is mainly determined by the system capacity (10.32). The "number of sheds" = number of rows is only used for shadings calculations. Increasing the number of rows means that for a larger proportion of rows the row-to-row shadings will be present. This is why the production decreases, because shadings are a bit larger.