Michele Oliosi

Yes I confirm, sorry for the formulation. There are a few errors like that, after our team is still mostly composed of french native speakers ?

Hi @laurahin, I second @dtarin's answer, and from a quick look the equations seem correct. Note that EOutInv = "Available Energy at Inverter Output". In this case it is to be interpreted as the maximum possible energy at inverter output, if the inverter operated at MPP. Hence EOutInv = EArrMPP - InvLoss The grid limitation is always effectively interpreted in PVsyst by inverters changing their operating point -> this diminishes the EArray just as inverter clipping would. This is the reason EArray = EarrMPP - (IL_Pmax + EGridLm). EGridLm here is the grid limitation loss. Yes ! We should have been more detailed in the documentation. Maybe some old FAQ post clarifies this, but I couldn't find it. Where did you get this info @dtarin This is likely the case, we will do our best to address this

Hi, Can you give a few more specifics on the orientation definitions. You mention: 16° tilt, 90° azimuth, South hemisphere fpr the fixed tilt. Your tracker axis azimuth is 0° correct ? Do you have a shading scene for the trackers or are you using the unlimited trackers option ?

Hi @kjs55 That would be difficult to implement at the moment. Can you give a bit more context about why (and the importance of) you would need the feature ? ? This is just to set that properly priority-wise. Thanks !

I see, and yeah maybe one of the legends (either power or energy) makes no sense. We'll fix that.

Dear @kjs55 In principle you can have multiple sub-arrays with the same orientation. If you get the error "orientation X is redundant" it means you have defined two different orientations that are the same. But nothing prevents you from setting two sub-arrays to orientation #1 (e.g.) in the system window. Regarding the albedo yes, that would be an interesting feature for bifacial. Note that albedo in the project settings is an albedo for "around the site" and not "in your site". The albedo below your tables is useful only in the bifacial case, and is defined in the bifacial model window. For the shading scene, I am not sure what you mean, since you can put all your arrays in the scene, no matter what.

Hi @kjs55 Can you tell us a bit more on the need for the Wh and W in the default units ? Indeed most projects to our knowledge are kW based. I remember one example of super small-sized project (a few cells) but in that case the whole interface in PVsyst had problems because of too much rounding. But yeah that makes sense and I'll add that to the suggestions. However we need to rething the appearance of the settings page beforehand. Not that much place left atm ^^

Hi thanks for the suggestion ! I will add this to our requests list ?

@dtarin is quite correct. The shadings in the unlimited sheds are idealized so the value won't necessarily match exactly the detailed calculation. The linear shadings are slightly overestimated. The shading-induced electrical mismatch losses are either overestimated or underestimated, depending on how many partitions ("modules in width") are chosen. Please look at the help (Project design > Shadings >Electrical shading loss according to module strings) for more information on this choice. When you diminish the number of rows, the importance of the first row increases proportionally. The first row isn't shaded, meaning that the shading decreases.

Hi @S Groenveld It depends on your orientation, meteo file and albedo. However with a well chosen south-facing orientation you should be able to get a bit more than that. Can you specify the orientation you are using ?

Hi @Amir This is normal, if your orientation is well chosen the GlobEff (plane of array, with irradiance losses), can be higher than GlobHor (horizontal plane).

Dear @Panch Karasani Did you try this with the latest version 7.2.18 ? I believe this bug has been corrected (it is a bug indeed), but if there are still some cases that are uncovered we will fix them asap. Thanks in advance

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.