André Mermoud

As explained in the warning message, you have to specify corresponding orientation parameters in the "Orientation" part and the 3D part. NB: By the way you should not define a "Horizontal E-W axis", but a "Tilted or Horizontal N/S axis.

When you create a shading scene, PVsyst checks the compatibility of your system, i.e. that your sensitive area is sufficient for positioning all the modules defined in the "System" part. You are strongly advised to follow the tutorial present in the main menu of PVsyst, just below the Help option.

The diffuse fraction is computed using a model (Liu-Jordan or Erbs, Perez-Ineichen, or others, described in the literature). The solar angles calculations are detailed in the help of PVsyst (Chapter "Physical models used"). The shading factor for beam is a calculation in 3D geometry, for a given sun's position. The shading factor on diffuse and albedo are integrals of this shading factor over the sky dome "seen" by the PV system. All these calculations are complex and cannot be obtained just from a formula.

The planned power is obviously 50 MWp. In PVsyst you can specify 2 different sub-arrays, one for eack kind of modules. You have detailed tool for the determination of the PNom ratio.

The files produced by PVsyst up to V 6.39 are written in binary format, and impossible to read by other means than PVsyst. The new version 6.40 will produce text files, easy to edit. However these text files are intended for internal use. We will not ensure any support about their interpretation.

Yes of course the simulation takes the voltages (battery and PV module) into account. The corresponding loss is named "Pmpp loss" in the loss diagram. Now a 60 cells module is really not suited for the direct charging a 24V battery bank. You should use at least 66 cells modules, the usual design is to use 72 cells. For better results, the MPPT controllers are now not much more expensive than usual switch-off controllers. And you get rid of the Module's voltage constraint.

Skelion exports models from the Sketchup representation, but the representation of objects in Sketchup is not really compatible with the way PVsyst is waiting for shading objects. You can try importing these scenes, perhaps they will look correct, but we don't guarantee the shading calculations. We will implement our own Plugin for Sketchup within the next months, with our own constraints about the structure of the object's representation.

With such an inverter, this is not advised (or not possible) due to the current limitation. However with other inverters (those with the secondary input dedicated to one only string, and when it is allowed by the manufacturer), you can indeed use only the main MPPT input. In this case you should inform PVsyst by using the "Adjust" button.

This is not possible in PVsyst. You should do different simulations with parts of your system.

I have given the answer to this question in my last post: However, since the redaction of this answer, the limits have been migrated to the Project's parameters (button "Albedo and Settings", page "Other limitations", parameter "Max. orientation difference for defining average (spread) orientation".

You have chosen an inverter with a special feature named "Unbalanced Inputs". This means that you have two different MPPT inputs (in this case, with Imax = 49.5A and 37.5 A respectivaly), named "Main" and "Secondary" inputs. With such special inverters, PVsyst requires that you define two different sub-arrays, one for each kind of input. In your case you will define the first sub-array for the main MPPT input, 3 strings and the corresponding orientation. And a second sub-array for the secondary MPPT input, 2 strings and the corresponding orientation. NB: You can add sub-arrays either by specifying the number (top left) or by right-clicking on the sub-arrays page titles. NB: The fractional and strange PNom values are due to the fact that the PNom of each input is shared as function of the Current's shares: 49.5A and 37.5 A lead to PNom = 13.7 kW and 10.3 kW.

PVsyst uses the one-diode model with slight modifications (especially an exponential behavior of the Rshunt as function of the irradiance). See the Help "Physical models used > PV module, model description".

Usually the PV array very rarely reachs its nominal power during operation. Except under special partial cloudy conditions (transitory conditions), or at high altitudes, the irradiance perpendicular to the PV module doesn't exceed about 1000 W/m2. But in these conditions the PV array temperature is at its higher values. A PV cell temperature of 55°C, with a temperature coefficient muPmpp of -0.42%/°C, will induce a loss of 12.6° with respect to STC (1000 W/m2 and 25°C). Now the inverter sizing is not really dependent on this: you can accept some hours of overload without loosing much energy. PVsyst offers an explicit tool for the sizing of the inverter. You can see that a PnomRatio (= PnomPV / PNomInverter) of 1.25 to 1.3 is quite acceptable in most cases. Inverter sizing conditions

With "normal" projects, PVsyst responds immediately as any other software. A long response time may arise during some operations, for example when you have a very big shading system. This is usually due to a recalculation of the interpenetrating objects at each verification of the calculation version (shading scene). You can desable this option in "Tools > Ignore interpenetrations of shading fields" in the menu of the 3D editor. Another example: Meteonorm 7.1 takes some seconds for generating synthetic data.

The difference represents 1.3% ... There may be some rounding uncertainty in the percentages, and the simulation procedure for stand-alone systems was not quite optimal in this old version 5.74 (there is some retro-action between the direct-coupled PVarray and the real battery voltage). With the next version 6.40 (to be released beginning of January 2016), the simulation of stand-alone systems has been deeply revised, and this balance is now quite correct (within 0.1 to 0.2%).

I don't know. Which version of PVsyst are you using? Did you specify "Mixed Orientation" for some sub-array? This could be an explanation for an old version.

I don't know. Probably the PV array is not defined correctly (perhaps a Polygonal field, with points counted anti-clockwise, which means a down orientation ?). Please send your full project, using "File > Export project"in the main menu, to support@pvsyst.com).

In PVsyst, the mismatch parameter is a constant parameter that you can set at any desired value. Now in the explanations I have not mentioned this mismatch in irradiance on a big array. You can include it if you want. However please observe: - The mismatch in important when acting on the current, i.e. in a given string. But between strings in parallel, the mismatch loss is negligible. Therefore this contribution should only concern short-distance irradiance discrepancies. - The cloud's effects are transcient phenomena. Their duration may be considered as negligible when calculating averages over hourly values. - Such variability may be accounted in the meteo data uncertainties, especially in case of unstable conditions.

I don't know. Normally the values of a given variable should match between the monthly table and the hourly values on the ASCII file, as this is the same variable in the program. However you are right. I just tried and also observed a slight discrepancy (0.8%, i.e. 0.3 kWh/m2/year on the horizon loss in the monthly tables). This is probably due to accounting the monthly values when the Incident irradiance is below the threshold of 10 W/m2, what is not done in the hourly values. I will check.

Yes, within a sub-array, PVsyst will share the strings (not the number of modules) equally between the specified number of MPPT inputs. Now if you have, for example 9 strings to be shared between 2 MPPT inputs, one will have 5 strings and the other one 4.

Please check that there is no "Tousend character" in your numbers (like for example 1'000).

The shading factor calculation will indeed be drastically improved in the next update V 6.40, to be released beginning of January 2015. However this problem is due to another problem (the verification of the shading scene), and desabling "Ignode Interpenetration of PV fields" should normally avoid it. If there is no improvement with the next version 6.40, please send us the full project to support@pvsyst.com, using "Files > Export project".

The calculation of the shading factor "According to module strings" is indeed not quite reliable in some special cases like this one. Please remember that this calculation should be considered as an approximate tool. The program analyses the shading state of each summit of the rectangle-string, and one intermediate point on the segment. Therefore a little shade on a part of the rectangle-string might be not recognized. For such a special condition, you should use the "Module Layout" option. Here the shading state of the corner of each sub-module is analysed. Now for the object not taken into account due to its base altitude, perhaps this is a result of the optimizing algorithm. In the 3D editor menu "Tools" please try to desable "Optimized shading calculation".

This is indeed the right way: in the part "Tools > Measured Data Analysis" you have to define the parameters corresponding to your system, and run the simulation. Now in the results dialog, you can open "Predefined graphs", and here you have several ways of comparing your data to the simulation. Sorry, this is a part of the program that has been neglected since a very long time. Even the DEMO project (N13 Motorway) doesn't work anymore. We will modernize it in a future version of PVsyst, and make this use more explicit and user-friendly.

In PVsyst and for Northern hemisphere, North corresponsd to Azimuth = 180°. Please see our FAQ How is defined the plane Orientation ?.