Michele Oliosi

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.

At the moment, changing the parameters programmatically can only be done via PVsyst (by using the batch mode to create and/or simulate new variants). In the future, we will extend the use of CLI so that parameters can be changed programmatically only using PVsystCLI.

I have checked further, and the pitch seems to be effectively changed, even for the backtracking algorithm. This is despite the message saying otherwise. The message seems to stem from a check, before updating the backtracking algorithm. It is therefore not relevant. Note that this does not happen in version 8 anymore, in principle. Have you checked ?

You still have the column "Pitch" in your batch file. Since there are only trackers in the scene, the pitch cannot be changed, which triggers the warning. What matters is the other column, "Trackers pitch EW". I would recommend removing the "Pitch column" and rerunning the batch. Note also that you should be mindful of how the backtracking parameters were set (3D scene > Tools > Backtracking management): Here the mode is manual (automatic unchecked). This means that if the batch mode changes the pitch, the backtracking algorithm will not follow, and the yield may decrease (either from being suboptimally oriented or from shadings). Instead if you choose "Automatic", then the backtracking will adapt to the changes from the batch.

Do you want to have the theoretical plane of array irradiance without shadings, horizon, etc, or the effective irradiance you would measure front side / back side ? The backside POA irradiance (without applying shadings or horizon) is GlobBak + BackShd (GlobBak has had shadings applied, so some irradiance needs to be reintroduced). GlobInc is the POA irradiance on the front side (without applying shadings, etc).

Okay, this seems to be a new bug. We will take a thorough look into this. Could you send us your project at support@pvsyst.com? This would be extremely valuable to fix the issue as quickly as possible.

You should check the following window : 3D scene > Tools > Tracker diffuse shadings definition. There you can check whether the representative tracker has shading masks (neighbors), if the loss is zero it probably is not identifying masks properly. You can switch to "all trackers" which is slower but is more accurate and robust. Let us know if that fixes the issue.

Thank you ! This may or may not be the reason, but now it is important to go through all the sub-arrays in the system window, to make sure the different bifacial models are active and well-defined. Indeed, there is a bifacial model per orientation now, to allow for different sets of bifacial parameters.

Indeed, the process is only manual for now. At some point we will get a tool to quickly assign orientations. PVsyst CLI will help with automatizing the "simulation" step, but for now no other steps, so it won't help here. By the way, what is your case, i.e., do you have more than two orientations in parallel electrically ?

Hi, yes that is technically possible, to associate each tracker to a different orientation. The basic TF losses are then obtained orientation by orientation so that works as well. The module layout will help in terms of shadings. One possibly missing feature is if you have more than two strings in parallel on the same MPPT and these are on more than two orientations, it is not possible to define that properly in the System part. Currently, string-to-string mismatch is possible to evaluate only for two different orientations connected in parallel. Finally, moving in the territory of custom tracker movement is more complicated. Indeed, you can apply a backtracking algorithm to each tracker movement, but that does not depend on the relative height. At the moment, only the ideal algorithm that avoids shades on a regular array of trackers is applied. Of course, we are working on a solution for custom movement, but that will take several updates before its release.

@FredrikRH it should calculate the bifacial gain for all orientations. Could you send your project over at support@pvsyst.com ? This would be extremely valuable to root out this bug.

Thanks @Maruyama. Indeed, this is the way to go. We need to give better guidance on this point including in the UI side of the software. We will be working on this.

@dtarin yes there are actually plans to completely rewrite the weather data import, to address these two issues and others in one go.

If you import sub-hourly data you can then use that as an enhanced MET file in your simulations. Here is a help page that breaks it down: https://www.pvsyst.com/help/physical-models-used/grid-inverter/subhourly-clipping-correction.html

Generally, smaller (rooftop) installations are more complex in terms of shading than large, regular ground mounted systems. In the latter case, strings are usually distributed on one or two large tables, and this pattern repeats, which makes it possible to use the “partition model” which is a simplified model to estimate electrical shadings. In the former, smaller rooftop case, it is best to use the most detailed modeling of electrical shadings. This is the module layout option, which necessitates to determine exactly which module 3D model is connected to which string. Even though your system is simple electrically, given the 3D scene, shadings will have a non-trivial aspect and necessitate this more advanced calculation. You can see one such complex shading pattern in your first screenshot.

It is partially solved in version 8, which should release (really) soon. You will be able to define separate bifacial models, one for each fixed tilt or tracker orientation. However, dome configurations are not yet covered by this update. We will work on it for a future minor release…

Hello, the forum language is English, but if you send your query to support@pvsyst.com we will happily reply in French. If this period is continuous within the interval of January 1st to December 31st, then you can use the following tool. From the project window, go to “Advanced simulation”. There you can change the start and end date of the simulation. If you then run the simulation by clicking on the “Run simulation” button in the “Advanced simulation” window directly, the correct dates will be set. However, the method you suggest will also work, i.e., importing weather data that covers a shorter period (possibly with holes).

Hi, not sure what you mean by using a CSV to build the 3D scene. Could you send your project at support@pvsyst.com? We would then be able to look at the 3D scene. In any case, take a look at 3D scene → Tools → Backtracking management. There you can verify the backtracking parameters.