Michele Oliosi

Hi, Please double check your PV system, I would be surprised that you have only 350 kWp. You can send us the full report at support@pvsyst.com there may have been a bug as well. The produced energy for a self-consumption system corresponds to the energy solar -> grid + energy solar -> user. The variable is E_Avail.

Hi, thanks for the feedback. Yes this is definitely a bug. We thought it just happened with the grid limitation, but apparently just self-consumption and AC / auxiliary losses are enough. I will update the issue and it should be fixed eventually in one of the future patches.

Hi Aquin, Thanks for the feedback ! Could you tell us a bit more on the differences you observe (magnitude, some examples,...) ? Is that systematic for all locations?

From version 7.2.15 on we have updated the "power sharing" interface. The previous interface, based on radio buttons, was showing limitations when there were many sub-arrays. In the new interface, one works by drag-and-dropping sub-arrays from the right panel, containing an exhaustive list of sub-arrays arranged by inverters, and the left panel, where configurations by grouping sub-arrays together. The logic is the same as in the previous interface. One should assign sub-arrays to a same group to balance the power between them. More details are given in the help page: https://www.pvsyst.com/help/powersharing.htm.

Hi ! We have changed the interface for this tool (because it was starting to show limitations for large systems). Now you need to drag and drop sub-arrays from the right hand panel into configurations. The procedure is described and shown here: https://www.pvsyst.com/help/powersharing.htm Btw, the trick of setting dummy MPPTs is quite correct.

It would be quite nice, although it would require quite some work, especially keeping the database updated (the electrical components already generate quite some work). It would be a good fit in the orientation window, at least as an informative list. I can imagine that a tracker database as a webapp would already be wonderful, having it directly in PVsyst even better. In the short term we will however probably prioritize covering more generic cases and offering a more detailed/precise simulation. Especially since more and more tracker manufacturers have special backtracking algorithms, covering these cases would probably be a good start already. But we're always discussing all sorts of avenues; we won't disregard your suggestion.

Hi, The ohmic loss fraction is specified at STC in the project windows. This means that in case of different current and voltage conditions the losses may differ (ohmic losses go like the square of the current). In the loss diagram you have the average over the whole year, so considering many different conditions. I think that for the LID loss this is just a rounding issue. 1.6% there probably stands for 1.55%. We will check this behavior in details. Regarding the two calculations, the second one is correct. If you want a loss as an absolute value, you should consider the diagram flow and apply all the losses above the LID loss.

Hi, What you have in the hourly results as PlAzim and PlTilt is the effective orientation of your planes at a given hour. These two values reflect the instantaneous orientation of your tracker. This is different from the nominal Axis tilt and Axis azimuth, which a) characterize the axis, not the plane, and b) are nominal and not instantaneous values. You can easily see the effective PlAzim and PlTilt for a given plane orientation by using the Orientation understanding tool found in the 3D scene > Tools

By the way, you should use the Hay transposition for more robust results with the retro-transposition. (In most versions of PVsyst this is done by default).

Hi Kurt, 1) You have to import your file via the "custom file" tool, meaning that many formats are allowed. Essentially any CSV with one time-step per line and one variable per column (hence at least one column for the POA or GHI, and one for the ambient temperature, but you can have more columns) will do. If there is extra information in the header of your CSV, the tool allows to disregard it. 2) PVsyst will reverse engineer (we use the term reverse-transpose) the GHI and DHI. In the end the discrepancy between the original value and the one in the simulation will differ for a given hour of less than a percent. Over the year the difference should be negligible.

Hi, sorry for the late reply. I suspect this is due to having 3 sub-arrays (from what I can see in the system window). Since you only have 1 column in the batch mode, it is impossible for PVsyst to know which sub-array to modify, which likely causes it to put the variant in an incorrect state. If you experience the same issue with a single sub-array, could you drop us a message to support@pvsyst.com, with the project (Home window > File > Export project) as well as the batch params CSV file ? Thanks in advance.

Ceará is very close to the equator, so you won't get much better than the horizontal plane (unless you are studying EW systems or tracking orientations), I think ?

Yes, that is indeed the case. When E_Grid is negative it means that in total you are drawing power from the grid.

Converter Loss over nominal converter power: this indicates that for several hours in the year your DC power is higher than the AC nominal power of the inverter. Therefore you are suffering from clipping losses. To reduce this, either reduce the DC power by decreasing the number of PV modules, or use a converter with more nominal power. Unused energy: this indicates hat for several hours in the year your system has available electrical energy that is unuseable because the tank is full. This may be due to having oversized the PV system, which provides too much energy. But it depends on your design choices; you may for example try to ensure that the pump will always function by oversizing the PV system.

We have found and corrected one bug in the following case: Create a variant from scratch Set a tracking orientation with backtracking (Set up the system – can also be set later) Add a shading scene: import it from a .PVC and click OK In the Near shadings window, when prompted with the choice, select “With backtracking” Compute the table: the shading factors will behave as if backtracking was not activated Simulate: results with too many shadings Recompute the table: the shading factors are now correct Simulate: consistent results Please let us know if the error does not correspond to the above procedure, especially the part in yellow. The error in the case above should be corrected in the next patch v7.2.17

Hi, Thanks for pointing this out. As @dtarin mentioned, it may be a display bug, which we will investigate and correct asap. Considering other reportings of similar inconsistences in the shading tables with PVC scenes, there may be another issue with the default backtracking parameters. However these errors have been very difficult to reproduce, but we are working on them. @Aaron3707 If you can send us your .PVC and/or project at support@pvsyst.com that would help us a lot.

The Phi angle generally represents the rotation angle around the tracker axis. For a horizontal axis tracker, it is 0 when the tracker is horizontal, so it roughly corresponds to a tilt angle. The BT limiting Phi angle is the maximum Phi angle reached in the non-backtracking (i.e. sun-tracking) regime. If the sun gets any lower, the backtracking is activated. The Phi angle (without limits) means the Phi angle if there was no backtracking and there were no tracker mechanical limits. It can be higher than the BT limiting Phi angle or the tracker mechanical limits.

You should raise it above the number of trackers, here e.g. 6000, the exact number being unimportant. Else the simplification is going to be applied anyway.

Hi, this seems normal, if you are using the same number of modules each time. The advantage of East-West (tilted) systems is that they compensate the worse orientation by allowing you to fit more modules per ground area. Let us know if it checks out !

Hi, Actually we check the areas orientation by orientation. Hence, it is really important that the orientations are well assigned in the system part. First of all, you can choose either to use the mixed orientation on a single sub-array. Or split into two sub-arrays, one assigned to each orientation. - Mixed orientation: at the bottom of the system window, you should assign strings (using a scrollbar) to this or the other orientation. Make sure that the number of strings has been assigned correctly (wrt the 3D scene) - Subarray per orientation: be sure that the orientations are well assigned. This is done at the top left of the system window. If you still experience issues, you can send us the project at support@pvsyst.com, we'll be sure to check it out. You can export a project via the main window > File > Export projects.

Dear julmou, thanks for the feedback, it is noted.

The conversion GHI / POA is not only geometrical, in that you have to decompose into different irradiance components: direct, diffuse, circumsolar, and so on. Each of these components will be transposed differently. Please read: https://www.pvsyst.com/help/models_meteo_transposition.htm Therefore, depending on the diffuse/global ratio, the transposition will yield different results.

Yes we are aware of these potential differences when the sub-hourly variability of irradiance is important and the Pnom ratio/Grid limitation clipping is high as well. Thanks for the article reference by the way. We are presenting a model to take this into account at https://www.wcpec-8.com/. The idea is to implement it into PVsyst.

Hi thanks for the info. Another post was already mentioning this kind of recomputing issues. We are investigating the matter but we haven't been able to pinpoint the exact issue yet. Regarding differences between unlimited sheds and 3D scene, yes, an example would be valuable. If you have such a project with an earlier calculation and a newer one, you can send it at support@pvsyst.com. It could be very useful for us in terms of tracking possible bugs. In terms of shadings there mostly have been bug corrections (as far as recent patches are concerned), hence the robustness has mostly improved. But the calculation itself has not changed. For complex tracking scenes, we have added the possibility to change the 40 tracker cap, above which the diffuse shadings calculation was simplified. This simplified calculation sometimes leads to incorrect results, whenever there are patches of trackers instead of a single homogeneous patch. If you are in such a situation, we recommend you check out this advanced parameter:

Please also check the time shift in minutes (open the meteo file). This may have an impact here.