Michele Oliosi

Yes. A bug was corrected in update 8.0.5, that afflicted cases where an averaged orientation had a large orientation spread. In these cases, the shading factors were pessimistic for low sun heights. Now things should work properly.

Dear Luis, Regarding the albedo, did you enter it in the bifacial model? For the purpose of backside irradiance calculation (and also for the light reflected from ground to front) the albedo should be entered in system > Bifacial system > first tab. Other than that, I wonder about your pyranometer placement. Do you have some images/details on that ? There could be some differences depending on the height at which they are placed (and also the pitch between your rows). Finally, could you share a screenshot of your loss diagram ?

1) I think this depends on how the 3D scene was defined. If they are defined as individual tables, they will be turned each around their own center. Each “array of tables” will be turned as one object with a common center to the whole array. 2) No, the azimuth is overridden. In general, when you have such questions on “what does PVsyst do in the optimization tool / batch mode” the best way to check is to use the batch mode. In the batch mode, you can modify the same parameters as in the optimization tool, and more. It has one interesting additional option, which is to store a variant corresponding to the batch modification: This allows to check whether the modifications make sense, afterward.

HI, there seems to be a bug that shows the factors as 1.00 even in cases where they are not 1. The displayed values are just updated when you enter the "Diffuse factor" tab in the horizon window. We will be looking into the bug. They are in any case internal variables, indirectly calculated from the orientation and horizon profile. You cannot set them manually. It is not equivalent to the far/shadings and horizon loss. These will in fact depend on details such as the exact weather data and diffuse to direct ratio, the sun trajectory, orientation of the tables, etc. This means that you cannot find a one-to-one correspondence between these factors and the far shading losses.

In the "auto altitude" tool you can also change the height of the objects above the ground. This will prevent having to change the height of the ground afterward.

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