Michele Oliosi

Year-to-year variability can be of about 5%, and climate change can also be a factor. Comparing a couple of years to a TMY may indeed give significantly different results. However, in some cases the satellite TMY / synthetic approaches may be biased up or downwards, that also happens. I would suggest communicating with Solcast and Meteonorm about that. I am not surprised at the 10% increase, because trackers on a topography are subject to some shadings due to the differences in height, even if you have the best backtracking algorithms. Note that in PVsyst we are a bit pessimistic regarding the backtracking algorithm. Also note that the irradiance optimization algorithm, instead, is quite optimistic ! Actual trackers may never actually apply such a strategy, there is always a question of lag, rotation speed, actual sky analysis and so on.

Hi, when importing, you should be wary of the following option: This will define the orientation properly. You can also try the East/West option. Note that you should not simulate East/West dome systems with a bifacial model. This cannot yet be calculated in PVsyst, a dedicated model needs to be developed still. In principle, the bifacial gain of E/W domes is negligible, unless the height of the dome is important.

Ah you have irradiance optimisation on ! Then your movement (therefore GlobInc) could be quite dependent on the weather file. It is therefore crucial to compare apples to apples and start from the same weather file and deactivate the backtracking. Do you have the results for that case ?

dtarin's answer is on point, thanks !

We understand their argument and it seems reasonable. But do not have enough studies to validate or invalidate their claim. Even TGY has its own specificities compared to TMY. The impact of changing from a TXY to another should be studied further.

I assume you are not using backtracking. Shading is not relevant for GlobInc, since it has not yet been applied. Weather can be a factor in so far that every irradiance component has a different transposition scheme. If the pattern of diffuse to direct irradiance is different, there can be differences in the transposed irradiance GlobInc. Other differences could be found in the details of your tracker definition. Are the stroke limits the same, for example ? Is there any axis tilt ?

Hi, in PVsyst topographies are imported by default without the flag “shadow casting”. You can double-click on your topography object in the 3D scene, and tick the checkbox "Enable shadow casting”. This should fix the issue.

Natively, the situation has not changed. The simulation output's shortest interval is still 1 hour. However, we have planned the sub-hourly simulation in our roadmap. Moreover, as a workaround, it is technically possible to run several simulations to emulate a sub-hourly simulation: https://www.pvsyst.com/wp-content/pdf-tutorials/pvsyst-tutorial-v8-pseudo-sub-hourly-simulation-en.pdf

In recent versions of PVsyst, nominal array energy balance errors are caused by the PAN file definitions. Whenever the one-diode model parametrization does not reproduce the nominal rating of the module, the issue will reflect at the level of results via this warning. I encourage you to open the module definitions, and observe the different discrepancies. Note that generally the fit cannot be exactly right between both values. Insignificant differences are no problem. The problematic case is whenever the difference between the two values become important.

@Bahattin Did you try to click on “Recompute” in Near shadings > Table ? This may fix the issue. Do you have more information on how you built your scene, and what were your detailed steps (regarding shading parameters) up to the simulation ?

Hello, There is a problem with the known format import function in PVsyst, and with the “Convert UTC to local time” in the NSRDB viewer.. The former has an issue recognizing files that are in UTC format, it needs files defined in local time. This would be easily fixed by using the “convert UTC to Local Time” functionality, but it doesn't work, unfortunately. What you can do As Linda mentioned above, you can still use the custom format import, I checked that it does indeed work. We will send you an example MEF (the conversion protocol) that should work. We will be looking into fixing this bug.

There has been a very small improvement to the way the shadings are interpolated at low sun heights and close to the “behind the plane” thresholds. However, the change seems rather large in your case. We would gladly take a detailed look at it, if you can send us your project over at support@pvsyst.com if possible. Thank you !

This does not seem related to the domes, actually. This type of error usually stems from how the module has been defined. However, the exact cause cannot be known from the message alone. There can be multiple reasons for it. If you could export and send us the project at the email written in the message, it would allow us to take a deeper look and find the underlying cause. Thanks in advance !

GlobBak is not technically weather data, since it depends on the system definition. You should instead run the simulation and create an output file: https://www.pvsyst.com/help/project-design/simulation/create-a-csv-file-of-hourly-daily-values.html So is BackShd. Note that if you have defined an horizon profile, you should rather use GlobHrz, instead of GlobInc, for the frontside POA. Indeed, the horizon also affects the solarimeter.

Right now we are looking at the next minor version of PVsyst (8.1), but that could still change (before or after) of course.