Michele Oliosi

Hi in fact PVsyst will compute the angle as follows: 0 = horizontal tables. But the angle is measured using the normal to the plane, so the angle is measured from the vertical axis to the normal to the plane. +-50° cannot be steeper than +-60°. You are probably mentioning this because of the drawing on the right of the orientation window. The green lines and red dot are in fact limits for the handle that you see in the middle with a blue line and a red dot (you can move it around to see the range). That corresponds to the opposite to the plane normal. It's not very intuitive but it is there historically, we will change this at some point.

We are currently working on the issue (thanks @Angelov for the example files). Basically the partitioning for NS-axis trackers in version 7.2.20 has a bug, that will take place whenever you open a tracker definition window, e.g. to try to modify the partitioning. As far as we know there is no workaround other than reverting to 7.2.19, but a corrective should come out soon (my colleagues already fixed it on our development branch).

Well noted, I made a reminder to update the information. Thanks !

Thanks for letting us know, indeed we need to fix this bug asap

Hi ! Can you send us the PVC file at support@pvsyst.com ? We'll gladly look into the issue. Thanks in advance.

Hi, The idea is to model upwards or downwards historical trends in terms of PV yield for a specific location. As you probably already understand, these trends depend completely on the location, and may be quite difficult to forecast. However if you are able to estimate this trend, then this tool will let you raise or lower the value used as P50. One simple case is when you are using older weather data. In that case you want to find whether the present weather yields more than past weather. Since it is historical data, you can more easily find documented trends for the specific location under study, either from publications or directly studying time-series data. The second case if forecasting, which of course is more difficult. Nonetheless you may be able to find some climate change forecast scenarios depending on your location. For example in Switzerland, the national centre for climate services provides this kind of information.

Hi, In the 3D scene, Tools > Orientation management tool, you will find a tool that will help you reduce the number of orientations. There are several ways to proceed, either semi-manually, or by changing the tolerance to identify different orientations. If you double click on an orientation, you can assign tables to it. In the above example all tables have been assigned to orientation #1, so you should first unassign them before assigning them to another orientation group.

@Falberto76 you can launch the simulation for shorter periods, but the same period for all the batch runs if I recall correctly. You select the option when choosing the simulation dates in the "Advanced simulation" window. Do tell me if that doesn't work.

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