Michele Oliosi

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 version, 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.

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.

It is easier to transform fixed tilt structures to trackers in the 3D scene, using the Transform menu. The other way around can be more of a hassle. The wind stow option is a good option. it necessitates however to import weather data from a file in which you prepare a wind speed time series > some number. Another option is setting the tracker limit angles to e.g. min X and max X+1° if you are okay to fix the tracker to this 1° range. X and X might work too, though I would double check the output with the X, X+1 to make sure it is consistent.

yes this is because of the ratio of width and pitch (GCR) which ultimately controls the tracking algorithm. In your case the GCR is .5. which explains that these two modifications are equivalent (approximately). I would still suggest the remove 1 cm option as better since it mimics most correctly what pvsyst does and is more general to other GCR ratios.

To compare with baseline pvlib, I would rather remove 2 cm to the "Sensitive width". Might be 1 cm, I am not 100% sure if 2 is double counting.

There is indeed a baked-in 1 cm addition to the effective width of the tracker (both sides) when using backtracking in PVsyst. This is meant to account for possible inaccuracies in placement. When this was implemented, it was expected that such precautions (leaving a margin of error) are applied in the field. Probably it is still the case?

Hi, LID is a degradation pathway, which you can see as a definitive change in the module performance. It occurs in the first hours of exposure to sunlight, but then the effect remains. Degradation is modeled as a fixed ratio for the whole year, but in reality this loss should increase throughout the year. This is why we choose the mid-year mark as representative for the yearly degradation loss factor. Hence the 50% applied on the first year. Module array mismatch loss is different from degradation, you find its value in "Detailed losses > Module quality, LID, mismatch"

As you can see in the frames above what you have highlighted ("Number of rectangle-strings"), on your table there is a non-integer number of partitions. This means that either your tables are not consistent with the string length (can be an integer multiple or a simple fraction), or the length 31.75 is not exactly correct as a string length. The difference in length you are seeing is probably just the 0.54 and 0.34 remainder of the partitions that has shifted the partitions on the table. If your tables are just a multiple of a string length, the easiest is to use "Number of rectanlge-strings" on the tables to simply divide the string in the correct number of partitions.

I see ! I just remembered that in this version (7.2) there is a bug for trackers. In the object management window, the number of partitions is not affected to the right variable. It is connected to the size of the partitions instead which in turn makes it not work. Please use option 3 or update the PVsyst version.

Hi, There is no object management window in PVsyst 6, so I assume you are using a more recent version. Which version are you using ? I have tried to see if solution 1 had a bug in version 8.0.19, but everything works fine. You are probably correct that solution 2 may have an issue sometimes. The zone tool is rather old and sometimes misbehaves. Solutions 1 and 3 should be equivalent.

No the tracker angles are the same. The interpolation profile is only a profile Shading factor = f(tracker angle). Therefore the only changes are in shading factors (for diffuse and albedo).

Hi the reason is in the calculation of diffuse and albedo shadings. For more information you can see here: https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html This calculation creates an interpolation profile based on the available tracker positions. By changing the tracker limit, the support pointss of the interpolation profile are shifted, thus leading to (in principle slightly) different shading values.

Dear @PranavK, this is new to us and unfortunately I cannot say much without looking at the project. Can you send it over at support@pvsyst.com ?