Michele Oliosi

Indeed, this seems like an unwanted regression. I will file a ticket about this.

This seems alright. There is no apparent reason here for GlobHor to be reduced. Can you check the MET file via this interface ? Database > Meteo tables and graphs

Unfortunately it is not present yet, I will add a ticket in our roadmap. In the meantime, I would suggest computing with the yearly energy injected into the grid, by dividing it by the DC nominal power.

Hi, You should use the module layout tool (detailed electrical shading calculation), which will estimate the electrical shading losses by adding the IV curves of each submodule. In such a way, you will be defining all these 3D scene modules by their string and inverter attribution.

Hi, which import mode are you using: known format or custom file? In the custom file case, make sure that the units are correct. Can you copy a snippet (a few lines) of your file?

Glad to be helpful !

Hi, NASA SSE in PVsyst is ancient data and I especially wouldn't rely on its wind speed data, probably it is zero as a placeholder for no data. They have had an update recently, I think, but we haven't updated on our side yet.

Indeed, PVsyst doesn't really treat the ground collision. It will be up to you to define the tracking range so that it doesn't hit the ground. I think all simulations steps in which the trackers are “below ground” cannot be trusted, although in appearance the results do not seem too bad.

It depends on whether you have chosen the “fast” mode or the “slow” mode. In the fast mode, the interpolation is used in the simulation. In the slow mode, the interpolation is shown in the iso-shading graph, but the simulation does the calculation properly with the 3D scene. It is a shading factor for albedo, i.e., it is applied to the albedo irradiance contribution to the front-side of the modules. This is why it is not weighted per energy, but is just a geometric factor.

Hi, I see, thanks for checking this. We would need to see the file to find out what is going on. Can you send us the source file over at support@pvsyst.com ? We will have a look asap.

Hi, yes, with caveats. Your trackers should all have the same nominal orientation, but they can follow the terrain. An error regarding discrepancies in the orientations may still be shown, but this can be bypassed by changing some tolerances in the advanced parameters. As a result, the reference orientation will be the average of all tracker orientations. There used to be a limit in the tracker axis orientation RMS deviation from the average to apply the backtracking. This is now mostly gone. However, the backtracking algorithm still moves all trackers similarly, according to the simplest backtracking on flat ground specifications. We do not yet handle independent trackers.

Not really, but you can also choose to ignore these gaps. In some situations, they do not really affect the shadings much.

Ok, so the difference occurs before the evaluation of EArray. My following hypothesis about what is happening is: The electrical shading factor table is changing from one simulation to the other. You can check whether this is the cause for the difference by switching to “linear shadings” and see if the difference persists. The fact that the table changes can be due to 2 different reasons: Since you are changing the pitch, the 3D scene is changed. This means that the shading factor table is recalculated. You should check that the backtracking works as intended. If you have perfectly flat ground, there should not be any electrical shadings, so you can output the variable ShdElec and check whether it is zero. The shading factor table of your variant has been calculated in a previous PVsyst version. In this case, the batch mode will make sure it is recalculated with the latest version. You can make sure this doesn't happen by viewing the Table in Near Shadings and clicking on “Recompute”.

Hi ! Currently, only the torque tube gap can be included in the tracker design. If the motor / pile gap is significant, I would suggest splitting the tracker into several trackers, with the size between the gaps as their individual size.

Ok, we will need to dig deeper. How about other quantities, such as EArray? In the report you find the yearly value in the table. You can also output this variable from the batch.

I see. This is normal then, because the edited GHI and DHI were chosen in order to give back GlobInc close to GlPMeas when transposed. If you change them, you will not get back the same value. When comparing transposed measured GHI and DHI to GlPMeas, you are accounting for: fundamental uncertainty in the measurement (calibration, noise, ...) uncertainty in the measurement system installation (orientation, position...) Hay model uncertainty Because of this I cannot tell you what is the single source of the 4.9% discrepancy. One thing that is on our roadmap is use one of either measured GHI or DHI in addition to GlPMeas in order to have a better equivalence at the GHI and DHI level. I agree that it would be better with such an option.

Each inverter has a nominal maximum power, which will determine the clipping level. This is defined in the OND, but of course you can also modify and save a new OND file.

There seems to be a "time zone" setting in the NREL TMY header, for example: 723740,"WINSLOW MUNICIPAL AP",AZ,-7.0,35.033,-110.717,1490 Did you try changing its value ? It may be zero currently and needs to be changed to -6.0, or the opposite way. Let us know if this works

The difference is related to clipping here. In the first variant, you have some grid limitation or inverter clipping, which leads to power peaks being all concentrated to the 12175-12200 kW bin.

Hi, There is nothing to do at the moment. Unfortunately, PVsyst cannot add a slope to the bifacial backside irradiance calculation. However, in the simulation, the front side irradiance is computed accurately with the 3D scene data, this doesn't change. Only the backside irradiance evaluation will suffer from not being a correct representation of the 3D scene. We will need to improve the model to correctly cover these situations, but it will take some time.

No the two questions are not really related I think. Here you are dealing with 3 things: The iso-shading diagram comes from the shading factor table. The table has discrete values. This is why the lines are "squared". Moreover the angles at which the table is evaluated is 2, 10, 20, ... which means that for 15° PVsyst will interpolate shadings from 10° to 20°, i.e.,the iso-shading will show non zero shading all the way to 20° even though the limit angle is 15°. If you want to avoid using interpolation, you can still switch to the "slow mode". If you use that, in the simulation, the shading will be accurately calculated for each simulation step. You are showing the electrical shadings table, which behaves more extremely. Even though you shade a small area, this means a lot of shading. In your case the shading at 10° is therefore close to 100% (electrical shadings).

In principle, you cannot input all of GlobHor DiffHor and GlPMeas when importing data. Which ones did you select in your MEF ? In order to use the GTI you need import only the GlPMeas. Where did you change the values manually ? I do not clearly see how to do that in PVsyst.

It may be due to the aging mismatch losses. Please check whether you have saved the mismatch values or not. If you can check the "Keeps calculated Mismatch values" box, please do so. Another way to investigate the problem is to display more variables in your output file. You can also define output files with monthly values and several variables, for the regular PVsyst simulation. Comparing them will lead you to the source of the issue. I notice that the units in the batch file output are incorrect, we need to address this.

Hello ! I'm leaving a translation in English - the forum communication language. ---- Good morning; After running several simulations of a certain project, I find that in several of the simulations, there is a difference in E_grid between the report and the Batch simulation. In the default simulation I have year 1, Pitch 6.5 meters, exactly the same parameters that I include in Excel BatchParams for the same conditions. I attach photos corresponding to the same simulation variable and without changing any data. I don't understand why this difference between report and Batch simulation, please if someone can help me I would appreciate it. Greetings to the entire community.

Hi, here the main error is related to the bifacial modeling. Once the backtracking in the 3D scene and orientation agree, there should be no issue with backtracking. Please see the following help page https://www.pvsyst.com/help/bifacial-conditions.htm It should help you proceed with your simulation and see what is wrong.