André Mermoud

First of all, please make sure that without backtracking you have well defined the mutual shad8ings in the 3D scene. Now with or without backtracking the result is usually very similar. With backtracking you loose irradiance due to the trackers's onrientations, when without backtracking you have shefing losses. But in both cases you intercept about the same "tube" of light. See our FAQ What can I gain with Backtracking strategy ?

Sorry, it is not possible to use Helios3D data with 2 different "nominal" orientations. The reason is that when accompanying a hill, the orientation of each table is different. With these kinds of scenes PVsyst has to evaluate an "average" orientation for the simulation. Now we did not yet implement the average calculation for 2 different orientations. This would be possible for east-west (domes) as the orientations are clearly different and we can easily define 2 groups of tables. It is much more difficult when the nominal orientations are close to each orther (like for example 2 sides of a hill). if the distributions interpenetrate, how to attribute a given table to one or the other average ?

This option only appears when you have effectively imported the Array temperatures along with your meteo data in the *.MET file.

This is exactly what I said in my first answer to this post. The active energy production will not be affected, until the Pnom limit (in kVA) will be reached. The power factor acts as a diminution of the nominal output power (Pnom) expressed in terms of active energy [kW]. In your example: Pnom (apparent) = 60 kVA => with 85% PF Pnom (active) = 51 [kW] will be applied for limiting E_Grid when running the symulation. PVsyst works in this way of course.

Please send us your Helios3D file (*.h2p) to support@pvsyst.com

You should now define your site in the database ("Databases > Geographical site > New"), and choose a well-defined site for the project.

With single axis tracking systems, the problem of defining a not null axis orientation is indeed not simple and confusing. In the 3D scene definitions, you have 2 ways of defining the axis azimuth: 1. - Either you define the axis orientation in the tracking parameters. In this case the orientation will be defined within the tracker's set object, and you will obtain trackers "shifted" with respect to each others. 2. - Or you define Axis Azimut = 0° in the tracking parameters, and you will have a correct "rectangular" disposition of your trackers within the Trackers set object. Now when including this object in the global scene, you can give an azimuth to this Tracker's object, and finally you will get a tracking axis azimuth with respect to the geographic coordinates. The azimuth specified in the "Orientation" part is indeed the axis orientation within the tracker's object (tracking parameters), it will be not null in the first case and null in the second case. The report will mention the final azimuth, with respect to the Geographic coordinates. NB: the backtracking results of a complex analytic calculation. We established the algorithm for the second case, but we couldn't find a satisfying one for the first case. Therefore the Backtracking is forbidden for the first case.

You can produce a CSV file of hourly values, showing any variable chosen among the >50 variables of the simulation, to be analyzed in EXCEL. For this you have a button "Output file", just before performing the simulation.

The shed-to-shed slope is indeed specified in degrees (this mention has disappeared from the dialog, perhaps hidden behind the up/down control, sorry). Now when you specify a terrain: - either you position the set of sheds as an object on your terrain. In this case the first table will be positioned on the terrrain, and the shed object will be considered as a whole, with its own parameters. - or you specify your system as a set of tables, each table will be positioned on the terrain independently.

If you didn't use the "transfer" function before the crash of your computer (which seems evident...), after reinstalling PVsyst on a new computer (or windows installation) you have to take contact with our administration admin@pvsyst.com.

We have to get instructions from SolarEdge for modifying the installing conditions (which have been established in close collaboration with the manufacturer). We are in touch with them.

First, please be aware that this image is not directly issued from PVsyst. If it is based on a PVsyst configuration, it has been redrawn. Now for reproducing this configuration, you have to know the details of the project (more exactly the calculation version) which was used as the basis of this configuration. There were probably several sub-arrays, with different MPPT inputs and string lengths. Then, you have to reproduce the 3D scene that has been used, i.e. the exact shape of the façade and the holes.

Solaredge has not shared theid latest Guidelines with us. However I don't understand well which limitation you are speaking about. Please give a screenshot of window in error, and the exact error message.

This means that you have defined efficiency curves for 3 different input voltages (see the "Efficiency curves" page). But these input voltages are not well defined (they should lie between the Minimum and Maximum MPPT voltages, i.e betqween 888 and 1275 V in your case).

You can manage the IAM parameters in "Detailed Losses > IAM". You can change the bo factor, or define a customized IAM profile. Here you have also a detailed tool for the analysis and comprehension of this IAM loss. But sorry, we don't have reliable information about one or another product.

Yes in the present time the tree are considered as absolutely opaque. It would be very complex to define a semi-opaque shading in our calculation framework. And moreover changing along the year ...

The PHOTON database is indeed no more available. They have changed their site and the Database page is not accessible. However we are not managing this tool in any way. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. For Crystalline modules, except Isc, Vco, Impp and Vmpp, nb of cells in series and module sizes, you can let all the other parameters at their default value.

You should ask our administration admin@pvsyst.com.

In the "Orientation" part, you have to specify 2 orientations. And in the 3D shading scene, you can: - either define 2 array of sheds, and place them Back-to-back, - or since version 6.42, you can directly choose the object "Domes".

Thank you. It is indeed a mistake in this text, we will correct it.

For the initial year specification when importing ASCII data, I don't know. At first sight we didn't modify anything here. We will check. For the list of modification, it is indeed in the release notes when you download the new version. You can get all modifications in the "Readme.TXT" file, or on our web site, menu "Software > Software developments".

The "Active area" is the PV modules area. In PVsyst, it is the area of one module (LengthxWidth) times the number of modules. The "Ground area" is the area occupied by the PV array (not strictly well defined). The usual definition of the GCR (Ground Coverage Ratio) is the ratio of the Active area to the Ground area.

Defining each table-module as one "rectangle" is the correct way. If the tables are subject to shades from surrounding (not-regular), this will under-evaluate the real electrical shading losses. If the modules are in shed-like arrangement (regular shadings on each row), and you have more than one string per inverter input, this way will give correct results. Indeed, as as soon as 1/3 of the sub-modules are shaded in a string, the string will be completely inactive (for beam component). See the explanation on How to evaluate the effect of by-pass diodes in shaded arrays?

There was indeed a problem when manually defining the monthly values of a site. This has been corrected in the version 6.43.

This arises sometimes (rarely), but this doesn't prevent working with the 3D editor... This editor will be completely renewed in a next version.