Michele Oliosi

The estimate for the time shift, when you import meteo data, is based on a comparison between the clear day model and the best days. You will find more details here: https://www.pvsyst.com/help/meteo_notes_timeshift.htm

@dtarin I raised a ticket we will see what we can do. I believe it won't be that easy (trackers at different altitudes complicates some calcualtions) but it would be a good feature.

Hi Julien, In this case I think SMA provides the curves in a detailed way, you can check this document (see screenshot) on the same page you sent, "downloads" tab. For your second question I cannot answer, maybe someone else on the forum will be able to

Hi ! The "ouput file" option is a way to export monthly / daily / hourly results. https://www.pvsyst.com/help/output_file.htm

Hi, after reviewing the scene, I have a better view of the situation. Basically, the auto-altitude tool is not working as you think it does. At the moment it is not possible to have an array of trackers that has trackers with different altitudes. What I mean is that because of the misalign, your array has trackers that are more or less distributed along the NS axis. In your case, you want the northernmost trackers to be lower in altitude than the southernmost, in order to follow the slope. However this is not what is happening in PVsyst, which has all trackers stay at the same altitude. For example for the array in red: now the horizontal view: For this specific case, I would suggest to try to work with zones, which produces single trackers instead of arrays of trackers. There are a few ways to do this, see for example :

Hi, Basically there are two situtations: One string per MPPT input. In this case, the optimizers allow for the current to remain the same as Impp, and you "recover" your electrical mismatch losses (i.e. the loss due to shading is mitigated). This is formally equivalent to the case where you connect several strings to the same MPPT input, but they are all shaded in a similar way. Several strings per MPPT input, but not all are shaded. This leads to a voltage mismatch between strings, which prevents you from recovering your electrical mismatch losses due to shadings. I'll try to slightly change the formulation in the help to make things more clear.

Hi, Thanks for the feedback. At the moment a workaround is to run the simulation first. Once you save the results, you should be able to go back to the horizon page and print it correctly.

Hello ! PVsyst will check whether the irradiance values seem realistic. It has happened for certain specific locations on earth (e.g. high altitude dry climate like in Chile and neighboring countries) this verification fails. If you think you are in one of these cases, you can change an advanced parameter.

Yeah that seems a good notion of GCR.! I will file a ticket to assess this change ?

Hi ! For us -10° is "just" the default value, and indeed I agree that in several places in Europe you may want to choose something lower than that. Of course in the end it is the responsability of the system designer to ensure that there is no issue, so being more conservative seems best (i.e. 20 or 10 years rather than 5). It is all a matter of how much risk you consider acceptable. Of course, economic considerations however will tend to pull the value upwards... but at the cost of increased risk.

@akyle you can send your project to support@pvsyst.com ! thanks in advance

For the report GCR: When you are using arrays such as in your scene: if I am not mistaken the GCR is computed as the ratio table width / pitch of the array, and then an average is done between arrays. In principle your scenes should have a different GCR (higher for the first one). Note for two axis trackers: by default the EW pitch is taken into account. If the EW pitch is zero the NS pitch is taken into account. This is not always accurate, it is mostly meant to give an approximate value.

Hi ! Thanks for reporting this issue. We will study what is going on. Can you try deactivating the multithreading ? We had a few cases where the multithreaded calculation was leading to small bugs. If you can confirm whether the situation improves it will help us better locate the issue. If you can send us an example project with that issue that would be great as well (Main window > File > Export project).

dtarin is correct, this is the current state of affairs. Regarding the spectral correction, I doubt this would come up soon. The effect of ground refelction on the spectrum of light seems complex to model (and maybe for a small impact overall?). Do you have any references on this topic ? Finally soiling is quite similar to backside shading, you can increase the percentage for backside shadings (one of the parameters in the bifacial model) to take this into account.

If I am not mistaken the limit for the number of points is not a hard one rather an order of magnitude. So it may work with twice 8000 points, to be tested. For the backside you are correct, we use a model that assumes a flat terrain and that does not rely on the 3D scene. A development is planned but other features are higher in priority, so we cannot say when the 3D bifacial will be published, hopefully this year but maybe next. Whenever PVsyst handles an "average orientation" such as this one, GlobInc is based on all trackers as a whole using the average orientation.

Hi, We have this possibility on our roadmap, but at the moment it is not natively possible to implement a monthly grid limitation in PVsyst.

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 !