André Mermoud

For the near shadings, there is a Tutorial with an example in the help ("Overview" / "Tutorials"). For the Module Layout, we did not write a tutorial up to now, but the procedure is described in detail (step by step) in the Help of the version 6: "Project design" / "Module Layout" / "Summary of the Procedure".

I really don't understand what you want to do. - For analyzing the behaviour under different irradiance classes along the year, you can do an histogram (see for example in the results "Predefined graphs", "Incident irradiation distribution" or "Incident energy distribution"). - In hourly data you cand choose hours with a given POA Irradiance (for example 500 W/m2). Now if you want to manipulate the input hourly data for getting specific values, you can do this in an EXCEL CSV file that you will import using "Import ASCII meteo files". But be aware that if you specify for example an irradiance of 500 W/m2 (GHI): - If the diffuse is null, the system will receive a beam of 500 W/m2 * cosi/cosHsol (where i = incidence angle, Hsol = sun's height ) - But the diffuse is never null, and the resulting irradiance on the array will be the result of the transposition model.

Yes, PVsyst doesn't understand the dot within a filename (except the dot of the extension of course). Please simply remove the dots (and other eventual special characters) and everything should be OK.

As they are connected in series, all the cells in the module are submitted to the same current. Now if this current is forced over the Isc of a given cell (horizontal line on the graph above), this cell is reverse-biased and "consumes" power (positive current, negative voltage).

PVsyst puts a default value of 1.5% for the array ohmic loss. It is an reasonable initial guess for your first simulations of a system. But after that you have of course to estimate your real array wiring resistance according to your own cabling options. There is a tool for helping you in this task.

I just defined the "Unbalanced" option for inverters that I knew. Now most of the inverters of the database were proposed by their manufacturers before defining this feature, and they didn't mention this capability. You can of course define this by yourself in the Inverter's parameters.

No sorry, there is no possibility for identifying the PV module's parameters used in a simulation. This is indeed a weakness of the result's report of PVsyst. I have to think about some solution, but it is really not easy ... By the way the parameters of the PVsyst database are proposed by the manufacturers, and may also be "biased" (although I try to have some control on this, see What explains the difference of yield between different modules?

The PV array is sized in order to provide sufficient energy during the worst conditions along the year, therefore based on the worst days series in your weather data. Now if you diminish the autonomy period, the probability of "bad weather" series will significantly increase on short periods, therefor requiring a higher PV power. In other words: if you have 2 day autonomy, your PV array should be sized for ensuring the energy needs during the worst 2-days periods of the year. If you have 10 days, the probability of better days duting this time is much higher. In practice, PVsyst proposes an autonomy of 4 days. This may be slightly diminished in southern countries (but not less than 3 days), and significantly increased in northern countries with highly marked seasons. When you undersize the batteries, they will work more. Then, the price of the battery pack is not only the initial investment, but also related to the ageing, i.e. the number of charge/discharges (replacement costs). On the other hand, if you design a very big battery pack (more than 10 days), the PVsyst calculation will propose a reduced PV power, and the batteries may stay in discharged state during long periods, which is also not goos for their health. With the present cost of PV modules, it is wise to slightly oversize the PV array.

In the main menu of PVsyst, please use "Files" / "Import database components". Now if you want to put these files manually, a detailed description of the data structure is available in the help "Technical aspects > File organisation > Directories contents"

No sorry, this is not possible in the present time. Writing simulation parameters is a difficult task as there are many different ones, for each kind of system or simulation choices. The CSV hourly file refers to a given "Variant", and the parameters are on the report of this simulation report. In the version 6, you have now the opportunity of performing simulations in Batch mode. You can define some varying parameters on an EXCEL document, perform the concerned simulations and get chosen results on the EXCEL document, thus allowing for direct parametric studies in EXCEL.

As explained in the FAQ referenced above, you have many different strategies when mixing solar system, batteries and grid. In your case the batteries may be charged either by the solar array or by the grid. Which will be the conditions and strategy for chooosing one or the other source ? The batteries will probably feed only emergency circuits in your system, involving a double-circuit in your building. How to define these needs ? When the batterie are full the solar array will inject its energy into the grid - through which kind of inverter ? (probably a standard grid-connected), In case of a weak grid, how to model the grid unavailability ? etc... Such an installation and operational conditions are too complex for being defined in a general software like PVsyst in the present time.

In PVsyst you can define only 2 different orientations. In the "Orientation" dialog, please choose "Heterogeneous fields".

In PVsyst all angles are expressed in degrees.

Please have a look on the FAQ What is the basic concept of Inverter sizig ?. And also use the graph when pressing the button "Show optimization" in the System definition dialog.

This drawing in the Wiring loss part is only meant for showing the wire disposition. Each inverter shown here schematically represents a MPPT input. Please apologize for the mention: I programmed this drawing perhaps 5 years before defining multi-MPPT's for the inverters, and I did not update it...

I don't know how you obtained this curve. But of course, it is strongly dependent on the reverse charactersitics of the shaded cell. When I tried to establish experimentally this little (very rough) quadratic model by forcing a fixed reverse voltage to the cell, the measurements were difficult as when heating up, the cell's conductance increased with the temperature, therefore dramatically increasing the current and so on up to the destruction if I did not disconnect within some few seconds. It is probable that your shaded cell's voltage saturates at around -10 V or -11V, and this will indeed result in your observed curve. However this tool is a pedagogical one (for explaining the phenomenon). Fortunately the exact behaviour in this region doesn't arise in the real life, due to the protecting diodes. Otherwise you would often have cell's destructions due to Hot-spots !

This is related to the font size you are using in your Windows installation. Choosing "Small fonts" in your Windows installation should in principle solve the problem. If not please see Problems in the report format

No, in PVsyst each MPPT input (each sub-array) should be homogeneous (same module kind, same number of modules in series).

Please see in the FAQ : How to use inverters with very different MPPT (like Tripower of SMA) NB: In the new version 6, you have the opportunity of defining explicitely such a configuration (i.e. a "Main" and a "Secondary" input) with the concerned inverters.

In the "Orientation" part, please choose "Fixed tilted plane" and you can define the tilt and azimuth. There is no difficulty.

If you have a "normal" grid at disposal, a stand-alone system is usually not very useful (not economically optimal). Now except grid, there are no much uses of the excess electricity (you could heat up water for example). Please see my comment about hybrid systems in the FAQ : Can I include a battery in a grid-connected system ?

You can import meteo data in ASCII for one only day (24 hours), it is the lower limit.

In PVsyst, the definition of the user's needs is specified in terms of energy. Now this energy may be used in any way. Either directly by DC appliances, or by AC appliances after an inverter. The load energy specified in PVsyst is the DC energy before the inverter. If you want to use an inverter you should estimate externally the required DC energy, taking the efficiency and the stand-by losses into account. In fact the main information expected from the Stand-alone systems simulation is the energy balance between the PV production, the battery storage and the energy use (including a possible genset). The inverter is not an essential point in this evaluation. An inverter for a stand-alone system is a completely different device than an inverter for grid-connected systems: - For a grid-connected system, the input performs the MPP tracking on the I/V curve of the PV array; and at any time, the converted power is determined by the suns' availability. - For a stand-alone system, the input works at fixed-voltage (the battery voltage) with an "unlimited" current or power; the power is according to the instantaneous user's needs. We have deeply renewed the treatment of the Stand-alone systems for the version 6.40. Inverters devices will be defined soon. This requires to define a new component type, and the corresponding database.

This depends on which kind of data you are importing. If you import Monthly values, you have to choose the time zone in the "Site" definition, and this will be used for the generation of synthetic hourly data. If you import hourly values: - either you import them from a "known" source referenced by PVsyst, and the Time Zone is usually mentioned in the header of the file read by PVsyst. You don't have to define it by yourself (exception: the helioclim hourly data don't mention it if I remember well). - or you import them from another kind of ASCII file, and you have to define the Time Zone in the associated Site file which defines the geographical coordinates. In this case be carteful: the chosen time zone should be closely related to the time steps of the ASCII source file. In the format protocol, you can choose whether le time stamps of the data source represent the beginning or the end of the interval. After such import of data, please carefully check the time of you data by respect to the internal time of PVsyst (i.e. the clear day model), using "Meteo tables and Graphs" / "Data quality check". NB: As with most of the meteo data, PVsyst doesn't take the DST (Daylight Saving Time) into account, and people usually choose the Winter time as reference. You have a map of the Time Zones over the world at http://www.worldtimezone.com/ as well as a summary of DST situations and dates on the same site http://www.worldtimezone.com/daylight.html Now PVsyst fixes limits to the differences between Legal Time and Solar Time, for avoiding rough errors. It accepts differences from -1 to +2 hours. If in some special cases these limits should be overcome you can modify them in the "Hidden Parameters", topic "Miscellanaeous".

When in "Tools" / "Inverter" database, you have a button "New". The easiest way: choose an existing inverter (analogous to yours), modify the parameters according to your datasheets, and save it under another name, thus creating a new component in the database. The filename is the "primary Key" of each database element. I have taken the convetion to define it as "Manufacturer_Model.OND".