Michele Oliosi

Hi @kjs55, In PVsyst we assume the normal Gaussian distribution, and the assumed P50 value (since the distribution is Gaussian, it is the median and the average) is E_Grid simul. In order to perform a Monte-Carlo evaluation, multiple simulations should be run, which is not how the tool works in PVsyst at the moment. Intuitively, I would assume that since the uncertainties are large and partially ad-hoc (and usually the main factor is the climate variability, for which I don't know the customary distribution -- I should check) that the details of the distribution don't matter much. However I can see how when you take into account aging, or when the weather statistics are well-defined, this could change. But yeah, indeed, adding a Monte-Carlo tool, maybe on the basis of the batch mode, as well as a distribution function selection would be interesting.

Dear @kjs55 thanks for the info !

Dear @dtarin You are right this may be unclear in the current version of the report. I will file this request to be considered in future versions. We will probably go with option #1 at first. Eventually we may apply #2 but we need to address several other changes in the AC side first.

For later reference (issue solved): Here the issue was with the pitch. The pitch not being homogeneous enough leads to PVsyst blocking the simulation. The limitation may be circumvented (at one's risk) by changing the advanced parameters as explained in https://www.pvsyst.com/help/bifacial-conditions.htm.

Hi @laurahin We just noticed the save button is missing... we'll add it in a next patch. In the meantime there is a workaround to save the file with the time-shift: instead of closing, change to another meteo file in the drop-down menu at the top of the window. You will see a notification that invites you to save the file. This can be applied to any MET file in principle, not just manually imported ones. When you are importing your own data, you should rather reimport the data with a new time shift.

Hi, Indeed this is not yet available. It should be possible in principle, I'll add that suggestion to our list.

You could sum the production hour by hour. Of course this is assuming string inverters. If you have inverters which share both orientations that is more complicated, you shoul still join the results step by step, and correct for effects such as clipping.

Hi @raulserr33, Please check this page first for general information on the bifacial conditions. https://www.pvsyst.com/help/bifacial-conditions.htm By looking at your scene and system, I do not see what is wrong with it. It is clear to me that the pitch is homogeneous, and you have gathered all modules into one orientation. Could you send your variant over at support@pvsyst.com for review ? We'd be able to check exactly which condition does not pass.

Sorry for the late answer and thank you for the extra information. Recently I have noticed that there is some (partial) information in english as well. However most of the documentation remains in Japanese. We have a better understanding of Japanese within the PVsyst team now, but still not to a fully technical level. There have also been a few questions from users on how to import NEDO data to PVsyst. For METPV, currently this is not easy because PVsyst cannot read hourly data arranged as lines corresponding to one day (with 24 hours on 24 columns). We haven't developed a code to convert it yet, but don't exclude doing this in the future. @Sadono the data you shared is quite useful in this regard. @michelessw We would be quite interested if you are okay explaining your procedure, and I believe it would help several users. For MONSOLA, the important lines are the monthly horizontal global irradiance (line 平均値), horizontal diffuse irradiance (line 散乱⽇射量 please correct me if wrong), and ambient temperature (line 平均気温). They should be available in the data, and can be used to define a site.

Edit: In my previous reply, I mention 350 kWp is surprising. Looking at the results, it is in fact more likely that the user needs is not well defined. As mentioned, please double check your system and user needs definitions, and we'll be happy to look at the details if you send us more info by email.

Hi, Which version of PVsyst are you using? In the latest version you can import from the 5.1 or 5.2 API, a button allows you to choose between both. In previous versions of PVsyst, PVsyst was using a given set of years, whereas for a while the choice was not given in the PVGIS website (and didn't match the PVsyst one). I think now you can see the years considered when using the PVGIS website.

The error is the backtracking gain over tracking without backtracking, so 1% in general-few% max. Note that the error was actually quite easy to spot for relatively flat terrain. Indeed, when you activate backtracking you should expect few losses in the shading factor table. Indeed, I am not sure about this case (selecting the backtracking pair). Additionally if you did not generate the shading table previously there is a chance the error had been avoided. I will double check this situation and get back to you. *Edit: if you select the backtracking pair, the backtracking seems to have been well activated (confirmed each time for a few tries). *Edit 2: If you generate the table only at simulation the issue was unfortunately the same. NB: these errors have been corrected in v7.2.17

Hi, yes I can give more specifics. Basically depending on the order in which you access the different windows when defining your system, it could happen that the shading table was computed without backtracking, even though you had selected backtracking in the orientation window. This happened more specifically whenever you used an imported PVC scene, because the trackers were not assigned the "backtracking flag" during import, and only by refreshing the shading window and/or recomputing the shading factor table the flags were updated. The impacted simulations were those that had an incorrect shading factor table, and where the "fast" option was selected, i.e. the calculation of shadings according to the table. The "slow mode" with the hour by hour evaluation was not affected. By the time of the simulation the all backtracking flags were set correctly. Now this specific error is solved.

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 ?