André Mermoud

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.

Please check that your inverter is correctly defined. This usually arises when the efficiency curve is not well defined.

As explained in the help, in PVsyst you should import the file "Obstruction Elevation" for import in the Horizon tool. However the "Far shading" loss is of course closely related to the horizon line you have imported. You can check that this horizon line as imported by your SunEye is correct, by measuring the altitude angle of some points of your profile (on site). NB: The Solmetric horizon profile will also include the near shading objects. The shades of near objects should not be evaluated by the "Far shadings", but by the "Near shadings" part of the software. Therefore you have to remove their contribution in the Solmetric profile if any (i.e draw a line of the "Far" horizon only).

This is not a problem of import, but just of display on the tables. The values in the program are not truncated. However decribing hourly values of irradiance with 0.1 W/m2 resolution doesn't make sense, as the measurements have a much higher uncertainty. The same holds for ambient temperatures specified with 0.01°C. Did you ever try to measure an ambient temperature with a thermometer ? Even with 1°C resolution the value will not be stable over one hour ! NB: The rounding errors of measurements are always randomly distributed: the variance on several measurements goes with 1/sqrt(n) (n = number of measurements). For one year (8700 values), this becomes 0.01 times your uncertainty interval.

The "Module Layout" part is not suited for such big systems. It should no be used for systems greater than 500 kW or 1 MW at most. See our FAQ With my big power plant, the calculation time is prohibitive.

The Ohmic loss is quatdratic (R * I**2). Please see our FAQ How to determine the wiring loss parameter?

Yes of course, PVsyst is able to perform simulations with arrays specified for 1500V or more (without limitation). However up to now, most of the devices were limited to 1000V. The limitations are at 2 levels: - The inverter definition: few inverters are specified for a Maximum voltage greater than 1000V. - PVsyst will forbid using a system voltage greater than the maximum voltage specified for the PV module. Almost all PV modules are specified for running in Arrays which don't overcome 1000 V (IEC specification). However you have more and more PV modules certified for 1500V in the PVsyst database. This limitation is in the PV module's definition, page "Size and technology", item "Maximum voltage IEC". If you want to modify this value, it is under your own responsibility on the field. The choice of IEC or UL limit during the sizing process is in the project's definitions "Albedo and Settings".

In both module, you have the same parameters (namely Rserie and Rshunt) and therefore the muVco calculated by the model is identical. NB: The muVco value slightly varies with these parameters, especially Rserie. But in your export to EXCEL, the column muVco corresponds to the value specified by the manufacturer. This value may have been specified differently. See our FAQ How to adjust the Voc temperature coefficient ?