Michele Oliosi

You can check the system window: there the nominal power should show up as kWp but with one decimal. As André said, there is a bug in the report. We still need to solve it in one of the upcoming patches.

Hi, You are probably right. Your observation that trackers with backtracking underperform is related to these inaccuracies, as well as the topography, see https://www.pvsyst.com/help/backtracking_onhill.htm Even small amounts of irregularities in the topography, shadings would be generated, hence leading to electrical shading effects. One option would be to add an optional extra loss as you mention, to be estimated by the user. Defining a default value for that would need an extensive study and is probably not realistic. More generally I would consider adding a set of generic "custom losses", that the user can define and add at some level in the simulation. I will add this to our possible tickets. In any case the discussion of these effects is a great and complex topic. Backtracking gathers a lot of expectations but it seems it will not always live to them. Moreover its implementation in PVsyst was complex and leads / has led to many discussions.

@julmou Yes the definitions seem to be the opposite. Many people use the term EW tracker when they mean a NS-axis tracker. It depends whether you think of the axis or the possible directions of the plane.

There are a few studies on the subject. Here is an example after some searching (behind paywall but you can access the plots) https://www.sciencedirect.com/science/article/abs/pii/S0306261916307085 The results of the study seem surprisingly good for vertical tracking strategies. I didn't look into the details (please do) but cost and shadings may need to be taken into account and probably will modulate the results. In any case, for simple vertical tracking, the threshold from which it is interesting reads 30°. However, I wouldn't be surprised if this limit is increased to more when considering all practical factor. NS axis or tilted NS axis are more interesting below that threshold latitude.

In that case you can convert tables to shading objects:

Hi, you can find most models used in PVsyst directly in the help. https://www.pvsyst.com/help/models.htm For some models you will have to go look for the related publication. Hope this helps !

You are right this is a typo. Thank you !

Hi, Thank you very much for the feedback. In fact, being able to display 3 decimals for loss percentages in the report is completely artificial. It was added probably because of some request. You should always keep in mind that in PVsyst changes below 0.1% are to be considered as irrelevant, and in some cases you will even find differences when saving and reopening a variant (some values are recalculated based on other variables, and the saving precision is fixed). In any case this is justified by the large inaccuracy of measurements and basically most inputs, but especially the meteo. That is to say, we will likely not increase the number of decimals in the losses. However I agree with you that at least the default 2 decimals should match in the output and input. We will check that that is the case.

It seems the plot in the right hand corner is a bit bugged. Thank you for the feedback, we will take this into account for our next improvements !

Hi, 1) is not just regarding the tilt, but really the angle between the normals of the two planes. Basically if the 1) limitation is not true (i.e. there are planes with more than 1° difference between their normals), you are passing from the "single orientation mode" to the "single heterogeneous orientation mode". The "heterogeneous orientation" means that although you have several (possibly many) plane orientations in your scene, PVsyst is using only fewer "average orientations" for the simulation. 2) 10° is the default limit above which putting two planes into the same average orientation is not ok, i.e. would lead to an unacceptable approximation. Putting planes together in orientations is done in the 3D scene, in "Tools" > "Orientation management" (https://www.pvsyst.com/help/shadings_orientations_dialog.htm). You can change this 10° limit to be more or less strict when including planes into an averaged orientation. I believe the option about Helios3D is not available anymore, now it should be treated as the other cases.

I see. There is no reason that the BkVFLss changes. What was the magnitude of the change ? For the losses after and at the inverter yes a change is possible. Indeed, what PVsyst computes is first the power without limitation, and then one readjusts the inverter clipping to obtain the desired (limited) grid injection. Therefore the losses in between may change. Basically, the grid limitation is anyway computed at the level of the inverters.

The 7.2.10 change impacts the albedo shading integral. Previous to the update there were no shadings on the albedo contribution for negative tilts. This has a tendency to slightly increase the shadings value so I don't think this is the source of the error. The 7.2.12 change only kicks in if you had selected "irradiance optimization" below the "backtracking" option in the orientations window. If you were using the irradiance optimization, this may be the reason for it.

Hi, I am not sure whether you have already, but you can drop us an email at support@pvsyst.com, ideally including your project and the two differing variants / reports. We will then be able to review what is going on.

At the moment IAM losses are automatically included in the irradiance contributions. Therefore, measurements (e.g. with a pyranometer) may differ from (GlobBak + BackShd). As you mentioned in another topic, we will think about adding an IAM loss estimate so that we can remove it from the PR normalization.

Thanks for the feedback !

Yes and yes. If you leave 25° & 25°/1000W you will get 50° at 1000W : 25° is the base temperature. If the inverter is cooled efficiently then yes you can put 0°/1000W as the proportional increase.

The system definition should match the entirety of the scene. To be accurate the partial shadings tool is really to be thought of as a subset of tables that will represent all tables in the scene for the purpose of shading calculations only. It does not allow to perform a partial simulation (over just part of an array). Indeed, currently the tables do not change colour. We need to fix that.

Hi, thank you for the feedback ! At the moment PVsyst would not be able to use this information for the simulation, contrary to the POA irradiance, which can be converted into GHI and DHI and therefore be used as input for the simulation. We hence still need to address the question of how to use this information. However we will keep your feedback in mind for an overhaul of the measured data comparison tool. This would be a simper use for this kind of data.

Following the update of IEC 61724-1:2021, since version 7.2.13 you will find a bifacial performance ratio in the results summary window. This bifacial performance ratio is computed as: PRbifi = PR / (1 + (GlobBak + BackShd)/(GlobInc)) (see https://www.pvsyst.com/help/performance_ratio.htm) Note that this may not correspond to notes 1 and 2 of §3.20 in the norm IEC 61724-1:2021, since it does not include the bifaciality factor. It is instead based on a literal interpretation of the IEC 61724-1:2021 §3.20 main paragraph.

Hi, Yes the standard PR in PVsyst is normalized with respect to the frontside irradiance only. Since version 7.2.13 you can find an adapted bifacial PR in the results summary. See https://www.pvsyst.com/help/performance_ratio.htm

Since version 7.2.13 you will find a bifacial performance ratio in the results summary window. This bifacial performance ratio is computed as: PRbifi = PR / (1 + (GlobBak + BackShd)/(GlobInc)) (see https://www.pvsyst.com/help/performance_ratio.htm) Note that this may not correspond to notes 1 and 2 of §3.20 in the norm IEC 61724-1:2021, since it does not include the bifaciality factor. It is instead based on a literal interpretation of the IEC 61724-1:2021 §3.20 main paragraph.

Since version 7.2.13 you will find a bifacial performance ratio in the results summary window. This bifacial performance ratio is computed as: PRbifi = PR / (1 + (GlobBak + BackShd)/(GlobInc)) (see https://www.pvsyst.com/help/performance_ratio.htm) Note that this may not correspond to notes 1 and 2 of §3.20 in the norm IEC 61724-1:2021, since it does not include the bifaciality factor. It is instead based on a literal interpretation of the IEC 61724-1:2021 §3.20 main paragraph.

Sorry my answer was not so clear. In the simulation, the temperature of the modules at a given hour is taken into account automatically of course. Meaning that if the modules at a given hour are hot, then they will be less efficient. (This is not affected by chosing 22 or 50.) This is what I meant by follow the one-diode model. You can find more information here https://www.pvsyst.com/help/pvmodule_corrtemper.htm The second part of my answer just meant: there is nothing special about "22°" in particular, and the choice of "22°" in particular in the project settings dialogue will not affect the simulation. It is just an example of a characteristic temperature (which in fact seems quite low in your case, maybe a choice due to low ambient temperatures).

The correction should come out in the next or in two patches time.

Hi, You should consider using the "Aging tool" that you will find in the advanced simulation window. This will take into account the yearly degradation, basically what you have done in excel. It also allows to access to the degradation loss window, which will give you more information on the aging loss. Note that you can only simulate a single year with the meteonorm data you have, because what meteonorm provides (in PVsyst) is a statistics-based synthetic year, similar to a typical year, that is not a real year per se. This is indicated by the year 1990 in PVsyst. You can simulate the aging through 20 years of simulations using the meteonorm data, but the same weather data will be used every year, which is not really realistic. Real years will be subject to year-to-year variations. Therefore you should maybe look into getting real time-series data for 20 years. One option (though it may have only 12 years or so) is: Main window > Databases > Known format : choose "PVGISv5 hourly time series direct import" in the drop down menu. This will download a number of time-series files, which you can then use in the aging tool above. NB: the aging tool is not available for stand-alone systems yet. In order to use it you should redesign your system as a grid connected one. However please first consider the stand-alone system to get advanced information on the battery sizing.