André Mermoud

This option "Partial shadings calculation" in the menu of the 3D editor is meant for defining a partial part of your system, in order to decrease the computing time of the shading effect. When using this option, the shading factor will be computed on this sub-part of the system, and applied to the whole system. There is no option for simulating the production of a single inverter (or any part of the system). If you want to do that, you have to specify only this reduced system in your simulation.

This location which stores the basic prices for the pre-sizing is in the "Hidden parameters". These are basic values, not really meant for being modified by users. Here it is only possible to specify basic prices in Euros. Now in all places where costs are involved in the software, you can choose the currency, and specify the exchange rates as you like (the exchange rates database is not really up-to-date: please check the values when using it !). The prices in EUROs specified in the Hidden parameters will be converted in the chosen currency. NB: Please be very careful with this pre-sizing tool and the proposed prices: this is a very rough tool, just to be used for a very first evaluation of the potential of a project. More reliable results will of course be provided by the detailed simulation ("Project design"), and here, in the economic evaluation, you can specify your prices directly in your own currency.

Please have a look on our FAQ With my big power plant, the calculation time is prohibitive. In the version 6.40 the shading calculations will be faster, and the tool for calculating on a partial system will be improved.

This is indeed a limitation of PVsyst: - with the Helios3D scenes (spread of orientations due to different baseslope for each table), there is a special mechanism for the averaging of the orientations. - This averaging has not been developed for the seasonal tilt option. The average is not defined for the Winter tilt, so that the simulation cannot work correctly. We will analyze the possibility of extending this option for a next version, but it is not trivial (and marginal in PVsyst).

PVsyst uses the one-diode model. It is very difficult and hazardous to get satisfying results with such simplified models.

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.