Michele Oliosi

At the moment it is technically possible to simulate with custom orientations, but cumbersome and very time consuming. We will improve this in the future, but it will take quite some time to implement a custom tracking angles feature. With the current version, you should use the batch mode, and a "Fixed Tilted Plane" orientation. Please define the 3D scene with just one array. With the batch mode, you should simulate different orientations, each time creating a hourly output file. Finally based on the tracker orientations given by the manufacturer you can select for each hour in which file to look. Sorry, as said this may be complicated. You can indeed maybe apply the same strategy with a single axis tracker and run multiple variants with different eg. tilt. It's worth a try. I am not sure why and how you would have only one tracker to backtrack. Could you give more details ? I believe "rough" is indeed the right term. The uncertainty may be larger than the gain of using backtracking over tracking. Not sure you could trust this result. Sorry, since this case is not very common I don't have that much experience. In this case the best would be to try different options and compare.

Hi, I second @dtarin's answer. As an additional note: in such a case it may also help to consider how you would effectively string the 173 modules. If some strings turn out to have a different number of modules (e.g. 17 strings of 9 modules and 2 strings of 10 modules), then you can prepare 2 sub-arrays. It will help if you have a multi-MPPT inverter, which you can then balance, or string inverters in mind. You can also modify a central inverter to accept two inputs, so that you can put all your strings on the same inverter.

Optimizing this type of system means changing the pitch / tilt / size of the tables. You can use the batch mode or the optimization tool (found in advanced simulation) to run multiple variants and find the optimum one. If you want to do so, in the 3D scene the tables should all be in the same array of trackers (grouped as one array, not individual trackers) ! Btw which type of vertical axis do you have in mind? Single axis shared by all tables (i.e. a large rotating surface, e.g. floating) Each table has an individual axis. Do the tables have a tilt ?

Still difficult to say at this point. Are there any shadings at that time? Possibly you can also try the slow calculation mode. It is possible that interpolations of shadings are affecting the results in some specific cases. Anyway, you may send us the project at support@pvsyst.com. We should then be able to look in details at some point.

Hi @TBatMS, Indeed, I see that this is happening whenever your trackers are defined as single trackers (e.g. when you import a scene from a file). (The report displays all the necessary info if the trackers are grouped in a tracker array, e.g. built within PVsyst). We will see that this is corrected in a future version !

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.