Michele Oliosi

@Alberto Cerrone for an unrelated question, you can check other topics on the forum or create a new topic, please. There is no need to consider 3 arrays as one string (it is actually not possible, unless you use the detailed calculation model via the “Module layout” option). The partition model is an approximation adapted to regular row arrangements. In such a situation, there is not much difference in having 3 partitions or 1 long partition.

We are aware that since December 18th, PVGIS has modified their format for the TMY output, which has affected the functionality of our API call. You can find detailed information about this change in their release notes here: PVGIS Updates, Bug Fixes, and History. We are actively addressing this issue, and a fix will be included in our next release, planned for mid-January. In the meantime, you can use the following workaround to bypass the modified format: Open the Databases window and click Known Format. Choose PVGISv5 Hourly Time Series Direct Import. Define your site by selecting a location from the list or using the interactive map. Import the available data from PVGIS by clicking Import. This will generate .MET files for each available year. Normally you would not run the simulation for a specific year, but an average/typical year based on data from a larger time period. After saving the .SIT file, you have the option to either create a synthetic year based on monthly averages, or to create a typical metrological year – TMY To create a synthetic year, click on the button "Synthetic gen." and Execute Generation. You can read more about the synthetic data generation in the following help page: https://www.pvsyst.com/help/physical-models-used/synthetic-data-generation/index.html?h=synthetic+dat To create a TMY, close this window and click TMY generation in the Databases window. In the dropdown list in the top, you can find the site you just created and all the .MET files for the specific years at this site. Pick a Generation method and click Save TMY. You can read about TMY data generation in the following help page: https://www.pvsyst.com/help/meteo-database/tmy-data-generation/index.html?h=tmy+generation These files will be saved in your workspace and can be used for simulations as usual.

Hello ! The issue is that PVsyst is not really yet able to define a bifacial model when there is only a single table in the orientation. While it may have seemed to work in previous versions, the calculation was probably not correct. This issue will be solved in an upcoming patch. Until now, the workaround to define a single table with a bifacial model was to put two tables in the 3D scene, and distance them enough so that there would be no shading between them. Here, since there are shading objects and other orientations, this is a bit more tricky. What I would suggest is grouping the single table from orientation 5 with those of orientation 3 (which have a very similar orientation). To do so, you can enter “Orientations management” and drag and drop the table from orientation 5 to orientation 3. If prompted, choose “create average orientation”. Another option is to go to the List and Management of objects (or CTRL+G) and simply use the drop-down menu to select the orientation 3 for this table. By putting them in the same orientation, you will be able to define a single “average” bifacial geometry model.

Hi, You can change the units in the report options:

Hello ! A) ReflFrt is not already included in GlobInc. It is okay to add it. Instead of GlobInc i would suggest using GlobHrz, if you have a horizon line. Moreover, depending on the positioning of the pyranometer, you may want to deduct the diffuse shading losses ShdDLss. B) ReflBck should not be added like you suggest. This is because it is already included in GlobBak. Instead, you could add BackShd (which was deduced to get to GlobBak), as a way to reintroduce the structural shadings which probably do not affect your pyranometer.

If you have both projects and variants, you can compare the reports, but I think this still categorizes as "manually reviewing". Unfortunately, no, there is no such export of configuration variables in a way that can be parsed. We have this on our roadmap, but at the moment bug fixes and other major improvements have a higher precedence.

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.

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).