André Mermoud

Your calculation seems to be correct. I can't understand that this is depending on the pitch of the modules: it is completely unrelated. However for the sunrise and sunset hours, the solar geometry is not calculated in the middle of the hour, but the middle of the interval between sunrise and the next hour. This may be the cause of your difference.

Which version of PVsyst are you using ? I had corrected the little discrepancy (0.7%) - which was due to a calculation artefact - some months ago.

The near shadings strongly depend on the spacing you have specified between your trackers. Please see the animation in the 3D editor for understanding the behavior of your system.

The best way for understanding this and identifying a parameter is to put a big value to this parameter, and observe the effect on the drawings.

I don't know if some modules of this technology are already commercialized. There is noone in the database of PVsyst.

If you have a big system (big shading scene), please check that - You are not using the calculation mode "Slow", which calculates the shading factor at each simulation step. - You are not using the "Module Layout" option, which is not suited for big systems (see Big systems calculation in our FAQ) Please also check that in the 3D editor, the menu option "Tools" / "Optimized calculation" is checked. The simulation may also be slow if you have a very big number of inverters.

Thank you for this remark. I will correct this.

Yes it is taken into account. The PR is based on the E_Grid value.

This is an interpretation of the muPmpp value, as specified on the datasheets (and usually on test reports) and representing a linear behavior. This new interpretation better matches the supposed linear behavior of the Pmpp. I doubt that many manufacturers have optimized this parameter in order to better match the simulations in PVsyst. Now PVsyst is an evolving program. We try to improve the simulation when we discover some weakness. If the results should be always quite stable, there were no more room for improving the simulation and the program would be frozen. NB: If you want to avoid this modification, in the Hidden parameters you can set the parameter "PVModules" / "Upper reference temperature for muPmpp default" = 25°C.

You can follow the Tutorial within the software (just below the help menu).

There is no tool in PVsyst for getting the "average" shades at each position of an area. However in you case, you can run the simulation, with the "Slow" option (calculation of the shading factor at each step, without using the table), and produce a CSV file with the Hourly values of the height and azimuth of the sun, and the shading factor. The hourly Shading factor will give you the number of hours with shadings. In the batch simulations, the only parameters of the 3D scene which may be changed are the pitch between rows and the plane tilt.

We have not yet taken the time to update this. It is a secondary question on our ToDo list.

This should be 1 indeed. There may be some artefacts in the diffuse integral calculation, especially if you have additional shading effects.

Yes of course. In a general way, when I add a functionnality I keep the existing (and pertinent) ones. This will be an additional option in the Grid Power Limitation management.

In the present time the limitation is applied to the inverter output. Therefore all losses after the inverter are effective losses. Now technically, this is probably a current option in the reality, at least for systems with a single inverter. Clipping the power at the injection point would imply that the power effectively measured at the injection point level would be communicated to the inverter's electronic control for adjusting its exact operating point at each instant. See the previous discussion Grid Power Limitation about this subject.

No, the PVsyst file organization is not customizable. You have to manually remove (or displace) files if you want to avoid them from the componernt's lists.

This file is in your installation location: C:\Program Files (x86)\PVsyst6.2.9\DataRO\ It will be recovered when you will update or reinstall PVsyst.

PVsyst checks that you have defined sufficient area in your 3D scene for placing all the modules you have defined in your "System" part.

I can't understand that. Please send me the Helios3DE files, as well as your project's file (*.PRJ) and the meteo file (*.MET), at support@pvsyst.com. And please also tell us which version of PVsyst you are using.

No it is not possible. A MPPT input should be connected to an homogeneous array, i.e. same module model, and same number of modules in series.

In the batch mode you can ask for saving the simulated results as "calculation versions" (VCi files) or not. The view of the report (and therefore the PDF) for an existing VCi file is straightforward, you don't need to perform the simulation again.

In the version 6, in the "Orientation" parameters you can indeed define "Multi-orientations", with up to 8 different orientations. If you construct a 3D representation of your system, you should indeed define fields in different orientations, compatibles with your "Orientation" and your definition of the number of modules in your "System". There is no limitation about the orientations differences as a shading table is now computed for each orientatin independently. Now when you define rows following a terrain you can indeed have several different orientations. In the present time this situation is only taken into account with 3D scenes imported from the Heliod3D program. In this case PVsyst will define an average orientation for use in the simulation. In the 3D editor, you will have a tool for the analysis of the distribution of the orientations of your tables. If the orientations distribution is too large, you have the opportunity of modifying the limits in the Hidden parameters (see the Help), at the price of a slightly lower accuracy of the simulation. We are now preparing the representation of a terrain directly in PVsyst without passing by Helios3D, and these possibilities will also be available in this new framework.

This is an excellent question. In the present time, PVsyst provides a pre-sizing of the battery capacity, which is computed using one meteo yearly distribution (from monthly meteo data). This yearly meteo is randomly generated (synthetic generation), so that you have a different result at each execution. The PLOL is highly dependent on the worst conditions, i.e. the duration of the periods without sun in the meteo series. We plan, in a near future, to extend this sizing evaluation over a set of multiple years generations, and give a distribution of the PLOL, allowing to establish a P90 (or any Pxx) probability. NB: if the battery is slightly oversized, for a given charging/discharging balance its lifetime will be extended. Therefore the higher investment price will be balanced by a lower "operating" cost (i.e. provision for the replacement of the battery). The important parameter here is the cost of the stored kWh, taking the number of cycles into account.

I don't see how to simulate such a special configuration in PVsyst. I didn't foresee the possibility a defining a transparent object. Defining thin objects are possible also with parallelepipeds, in any version. I didn't remove any possibility about this since it was implemented. However this is not a good way: the "thin object" definition is really for taking the size of the object into account, for the electrical losses. If you define a glass as a thing object, it will produce a 100% linear shading (as an opaque object).

In the present time, it is applied to the inverter output, and with an identical relative Pnom reduction for each inverter. We have indeed to do some developments for appliying it to the E_Grid value, and balancing it between the inverters if the sub-arrays are different. This is a not trivial modification of the simulation process, because we have to compute the full system yield before applying the reductions of power. This is on our ToDo list.