André Mermoud

This tool is only a guide for helping you when choosing an orientation. It is based on a very quick and rough calculation from monthly meteo values. I don't know why you have such a difference: perhaps before the simulation the calculation was based on the Project's site, and after on the Meteo hourly file (according to its availability at the calculation time). Or perhaps you have changed the transposition model from Hay to Perez. By the way these rough values are not involved in the simulation process in any way. They are only indicative. If you want a better orientation optimization tool, please use "Tools > Transposition factor" which provides a detailed calculation based on a hourly meteo file. However if you have shadings (namely in a rows arrangement), please remember that these optimizations are no longer valid. In the case of rows, you should use the button "Optimization tool" just before the simulation.

We consider that defining the angles with 0.1° accuracy doesn't make much sense, neither in the reality nor for the simulation results. Did you ever try to position a solarimeter or a module with an accuracy better than the degree in the space ? This is very difficult indeed without sophisticated scientific instruments.

This is not an error. In the "Module Layout" part, where we are interested in filling an available area (called "table") with modules, the Module Layout working area doesn't represent the shading scene. Each table is shown in its own referential, and you can displace these tables as you like for "optimizing" the ease of use of this tool.

You are right. There is an ambuguïty here. Up to version 6.38, the check of the discrepancy between the Imp*Vmp value and the Pnom(STC) was essentially done as a warning, especially for measured modules, when the Gref and Tref are not the STC values. Since the version 6.39, PVsyst applies a "strict" check for avoiding that manufacturers use am increase of the Imp*Vmp value as a way of compensating the positive sorting. Please see Why is the Pmpp of my module different from the specified value ?. This limit of 0.2% is only applied to the modules specified with STC (Gref=1000 W/m2 and Tref = 25°C).

Sorry, this behavior is not implemented in PVsyst. I don't see any way how to do that with the present versions.

When you are in "Tools > PV modules", clicking "Export" will produce a message explaining that from now, you can select several modules at a time (using the Shift key, as usual).

The solution proposed by Jen H is quite correct. You could also define 2 sub-arrays, each with one MPPT input: one with 5 strings and one with 4 strings. This would be the solution if you defined groups of strings with a different number number of modules in series.

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.