André Mermoud

It is not possible. Probably you are not searching the correct data structure. You should have a look in your own workspace ( "My documents" \pvsyst4_Data\Components\Inverters\).

In the "Tools" part, button "Tables and Graphs of Solar Parameters", you can get graphs and tables of almost any geometric angle (except for tracking). Now you can also get these values in the CSV file of hourly values produced during the simulation (in the "Simulation" dialog, button "Output file").

There is no limitation. However the calculation time when computing the shadings may become prohibitive. Especially if you calculate the electrical shading effect using the Module Layout part.

This quantity, which appears on the loss diagram, is named EArray. It should ne be confused with EArrMPP, which is the potentially available energy at Pmpp. If the inverter has limitations (for example power limitation), it will choose another operating point on the I/V curve, and the power at the inverter input will be diminished.

The maximum available power as function of the temperature of the inverter has been introduced in the version 6.27.

The time zone (hour difference with respect to GMT) is necessary for the calculation of the Legal time, with respect to the Solar time used as basis for the solar geometry calculations. In most cases, the Time Zone value is close to value of the the Latitude/15°. Usually, it is increased by one unit for "Summer Time", but PVsyst uses to define the "Winter time" only. For avoiding bad sit definitions, PVsyst fixed a limit of -1 to +2 in the Hidden parameters, topic "Miscellaneous Meteo, Simulation...". Some regions (especially in China) need a different Time Zone value; in these cases you have to enlarge these limits.

Managing the shading scene in a CSV file is really not a simple thing it the general way. You have quite a lot of different kinds of objects, with different parameters and a specific construction. In the next version 6.40, the data files (including the *.SHD file) will be available in text format with "key-value" pairs, so that you will perhaps be able to slighlty modify your shading scene. But the program has its own logics, and respecting this logic will not be easy.

In the main menu "Files > Workspace", you can use the button "New" for creating your workspace.

You cannot export the whole table at a time. You can export a selection of components using "Databases > PV modules", When you choose the button "Export", you have the opportunity of selectring several devices using the Shift key. You will find a template of the EXCEL file "Components.XLS" for receiving these data in c:\Program Files (x86)\PVsyst6.xx\DataRO\PVsyst6_Data\User\

The Meteonorm DLL used in PVsyst (program provided by the Meteonorm team), requires that you have the Microsoft .NET Framework 4.5 or later installed on your PC. If it is not installed or obsolete, you should install it either from Microsoft website or by using Windows Update. However due to the fact that Microsoft has stopped the maintenance of Windows XP, this version 4.5 of .NET cannot be installed on XP. Therefore you cannot use the Meteonorm DLL V7 in PVsyst under Windows XP. The only solution is to pass to a higher version of Windows. NB: The synthetic generation of hourly values from monthly values uses the Meteonorm algorithm. Therefore it is also impossible when working under XP. In the next versions from V6.40, PVsyst will use the internal algorithm of PVsyst for this synthetic generation when .NET V4.5 is unavailable. Now Meteonorm also sometimes produces an error for some given sites (very rarely). If you get such an error, slightly modifying the coordinates (latitude or longitude) usually corrects the problem.

When you follow a terrain with your tables of modules (i.e. when you incline the base of your modules), the real orientation of the plane of array changes. This is especially the case with scenes imported from CAD software like Helios3D software, PVCase, Sketchup, etc. See https://forum.pvsyst.com/topic/30-with-sheds-on-a-tilted-roof-pvsyst-changes-my-orientation/#comment-30 Average orientation Therefore, when you distribute your tables on a hill, each table will have its own orientation depending on the slope of its basis, so that you will have a distribution of orientations. This may result in an error "You have defined fields with XX different orientations, you cannot define more than 8". You can analyze this distribution and modify the tables that are attributed to each orientation group in the menu of the 3D scene, "Tools > Orientations Management". For such a situation, PVsyst will use the average orientation of the distribution in each orientation group for the transposition step in the simulation. When importing or creating a 3D model with non-uniform table orientations, PVsyst will automatically create the orientation groups according to a limit discriminating angle. This limit is specified for your project, using the button "Project's settings" ("Albedo & Settings" in older PVsyst versions), in the tab "Other limitations". For automatically getting one only average orientation, you can increase this limit, at the price of a slight loss of accuracy in the transposition calculation. If the automatic grouping of orientations is not satisfying, you can manually adjust the attribution of tables to the groups as described above. Several Average orientations If you decide to group the tables in several average orientations in order to have more accuracy in the transposition calculation, you should keep in mind, that in the 'System' part of PVsyst the sub-arrays are linked to a single orientation. You therefore need to make sure, that splitting the tables into several orientation groups should stay compatible with the sub-array organization of the PV system you are designing.

I don't understand well the first question. In the module layout part, you can add or suppress modules using the righ button of the mouse. When defining the "Module layout" part, you have to define exactly the number of modules you have specified in your array in the "system" part. Now for the second question, if you have different sub-arrays in different orientations, the fields of each orientation (in the 3D system) should have sufficient area for installing the modules specified for the sub-arrays in this orientatinon.

PVsyst is able to read the files produced by any older versions. But the inverse is not true (upwards compatibility). When trying to open a file created by a newer version, the data formatting may not be recognized, and it may crash (sometimes with the message "Ask for XXX memory bytes). This arises namely when you try to open a file of version >= 6.40 in a version <= 6.39: The format from V 6.40 has been completely changed (text files). There is also a significant format change between V 6.53 and 6.60. Now when opening the "Projects" part, PVsyst tries to load the latest project and latest Caculation Version used in the previous sessions. If this file is corrupted (or more recent) this will result in a crash of this kind. For avoiding this the only way is to manually remove the concerned file (project) from your data (using the Windows file explorer in your " \PVsyst6_Data\Projects\" directory).

Which version of PVsyst are you using ?

Getting data for sub-systems or sub-arrays individually is not possible in PVsyst. You should perform a separate simulation for each sub-system you want to study.

Please see our FAQ What is the shading loss "according to module strings" ?

There is a limit value for discriminating when 2 arrays have the same orientation. This is in the Project's definitions, button "Albedo & Settings", page "Other limitations" > item "Discriminating orient. differences between shading planes". This is normally fixed at 1°, but you have perhaps increased it by accident.

Thank you for the suggestion. We will indeed think about periodical saves during the calculation. For the slowing of the full system by heavy shading scenes, this is not normal. In the menu of the 3D editor, please check the item "Ignore field interpenetration check" which should become "Enable field interpenetration check". This option is usually very time-consuming.

As you say, there are many models proposed for different technologies. These models usually require meteorological information (like precipitable water contents, or humidity), which are not yet implemented in the import and treatment of meteo data of PVsyst in the present time. We intend to do so in a rather near future, but we have still other priorities in the present time. NB: The instantaneous shifts may be important in some situations, but the annual balances are usually rather low. Except perhaps for specific technologies like CdTe.

When defining the Power factor, you can also define the corresponding Tan(Phi). You can simply define a negative Tan(phi). By the way in terms of Apparent energy, the result is exactly the same.

There is probably a problem in your system's definition, that I don't identify. Which version of PVsyst are you using ? Please send your whole project (using "Files > Export projects" in the main menu) to support@pvsyst.com

OK, I was not aware of this limitation of 400 trackers, and I have increased this limit to 1000 sheds or trackers. However such a number of trackers doesn't make much sense: if you have, say, 6m between trackers, this represent a width of the PV plant of 6 km. If you want to increase it you can simply define different arrays. Now if you have backtracking, it is quite normal that you don't have any electrical losses, as you don't have shading losses on the beam component (by definition of the backtracking strategy).

The format .h2p has been developed in collaboratioon with the Helios3D team, specifically for the import of helios3D files. It has not been published, and we don't intend to completely document it in a near future as it is still evolving, nor to support its use. Skelion has used it for their plugin, but without any contacts with us. PVsyst doesn't support the Skelion files.

Yes. The management of the grid limitation is indeed performed by the inverter's control circuits (the Power information at the injection level should be an input information for the inverter). The limitation itself is done by the inverter, and is considered equivalent to a limitation of the nominal power. We didn't define a special loss variable for that.

The diffuse shading loss is supposed to be "uniformly" distributed: you don't see any "shades" on the array due to the diffuse componrent. Now the elctrical losses are due to a mismatch when some cells only are shaded within a string (or an array). This cannot occur with the diffuse.