André Mermoud

In your first step, you have defined: - 4 inputs (which are just the connections) - No use of MPPT. You should check "Multi-MPPT capability" and then define 3 MPPT inputs here. - Save the inverter under another name. After that you can define a sub-array with 2 MPPT inputs (2 strings) and the second one with one MPPT input, and everything should be OK.

During sizing, the maximum voltage limits are to be applied to the Voc voltage, not Vmp (voltage in open circuit at low temperature) ! If you have defined a maximum area in your sizing conditions ("Presizing Help" box), the program will check it and warn you. You can simply increase this value if it doesn't correspond to your reality, or put it at 0 for ignoring it.

We are preparing a portuguese version for the version 6. It should be available within some few weeks/months. Ground-measured irradiance data for Brazil are rather scarce. In PVsyst, the NASA-SSE and perhaps Retscreen can provide monthly data. If you can obtain data from your National Meteorological Service, PVsyst provides a tool for importing hourly values in almost any ASCII (Text) format. The future version 6 of PVsyst will give access to the full Meteonorm functionnalities for getting meteo data at any place on the earth. The kWp is the definition of the PV installed power. The energy produced with this installation (expressed in kWh or MWh) will be the result of the simulation. It is not a sizing parameter. You can use the "Presizing" part for a quick evaluation of the energy produced by a given installed power in your situation (meteo, orientation). But don't consider the yield of this Presizing part as an accurate result !!! The definitive system should be studied within the "Project design" part.

In the "Project" part, "Site and Meteo", you can redefine the project's site and associated meteo. After that you can rerun the simulation for your calculation versions. If you had saved the previous simulation, the saved version will keep its results with the preceding meteo data.

Is your logo in BMP format ? Do you see it when importing it in the "Status and Activation" window ? Does the path to this logo (or its filename) contain special characters like accents ? If everything above is ok, please send me this logo file and I will check here.

I have found the problem. It is related to the Internationalization parameters of Windows. I have corrected it in the latest version 5.63. Hoping this corrects this problem for everybody...

PVsyst doesn't avail of a model for generating hourly values of wind velocity (I really don't know how to generate such data). Therefore the values cannot be imported from Daily values ,and the reslut is 0 I could indeed envisage to put the daily value as constant over the day. I will think about this for a next version.

The 3D shadings part doesn't recognize field orientations as "different" when the angle difference between their true orientation is less than 3°. You can modify this limit of 3° in the main menu "Preferences" / "Hiden parameters" / "Detailed Simulation Verification Conditions", topic "Shadings: max orientation difference between shading planes". NB: the "true" orientation is calculated in the 3D space by the scalar product between both orientation vectors. For example, if you have 10° tilt planes with 16° azimth difference, you have an orientation difference of 3°. This value is shown in the "Orientation" dialog, label "Angle between planes". NB: With such a low difference in orientation, you can also avoid using "heterogeneous planes" and choose a single average plane (say, at 8°oriention).

You can get such specific data from the companies SolarGIS or 3Tiers. If so, you should ask for the data in the PVsyst standard format. But these data are for pay.

I don't know exactly what you are doing. PVsyst cannot treat data of less than one day. If so the missing hours of the day will be filled by zero values. But in the Comparison tool (if you are using it) it is possible that the 4-hour sample leads to a crash. Please let me know the details of your problem (screenshot of the whole screen) when the error occurs.

The Photon database web format has indeed changed in June 2012, and this change has been taken into account since the version 5.58. If you reinstall PVsyst over your old installation you don't need a new code nor transferring your license. However if you have reinstalled it in another disk you should indeed ask for a new code.

You have to redefine your inverter as a device with 5 inputs, one for each string. After that you can define a system with 2 subfields: one with 4 strings (MPPT inputs) and one with 1 string. Please see "How to use inverters with very different MPPT input like SMA tripower ?"

Please explain what doesn't work with the import of PV modules. Be aware that the PHOTON database is not perfect. Sometimes some parameters are missing, so that PVsyst is not able to use the concerned module. Please carefully read the warning when importing the module. Which browser are you using ? Currently Internet Explorer, Firefox and GoogleChrome work quite well.

Yes of course. A single silicon cell has usually a Vmpp of about 0.5-0.51V at 25°C (up to 0.57V for the special Sunpower technology). The Sunpower modules of 435 Wp have 128 cells in series.

Did you read the first answer to this post ? What is still unclear ?

As mentioned in the help, we propose a model (energy balance) for the determination of the PV module temperature during the simulation, but we don't have assessed values for the parameters. The parameters Uc and Uv are to be specified by the user. They are highly dependent on the layout of the system and the wind measured values (just above the plant or meteorological at 10m). But we don't avail of reliable long-term measurements for these parameters in any conditions (free, insulated, with air duct, as function of the tilt, etc). The only values proposed are according to my own measurements on 2 or 3 installations, or the values proposed by a third party in the US for free-standing disposition: Uc = 25 W/m²·k, Uv = 1.2 W/m²·k / m/s But I am not able to provide evolution as a function of the tilt angle. To my mind, theoretical air circulation thermal models may help, but are not sufficiently reliable. This should be measured on-site (the parameters may be extracted from long-term measurements of TAmb, Tarray, Ginc and Vind velocity).

I don't have definitive answers. Which version are you using ? Until version 5.57, there were an error in the simulation process: when the Vmpp was lower than VmppMin (il_VMin loss), the overpower was not checked. This may have some effect in systems with low Vmpp value (by hot conditions). Since 5.58, this has been corrected: The overpower increases the Voper value, and is comptabilised first. Usually this brings the Voper over the VmppMin value. Now with highly oversized arrays and high Vmpp (more modules in series), you have the risk that the overpower correction leads to an operating voltage higher than VmppMax, and in this case the inverter has to stop completely (it cannot find a suitable operating point), leading to high overpower losses. The losses at very low irradiance are quite normal, I don't see where is the problem.

The exact term should be "Controller" indeed. I kept the term "Regulator" (from french) for historical reasons up to now. The functions of this device are: - management of the battery: cut the PV array when full, cut the load when empty. - eventually perform power management (MPPT or DC-DC controller). The inverter for delivering AC power to the user is not comprised in this device, and is not defined in PVsyst in the present time. The PVsyst load definition is specified in terms of energy needs. If you are using an inverter, you should take its efficiency and stand-by consumption into account externally.

The first assessment in red is indeed strange. It should be a warning in orange. The lower limit of 78 Strings corresponds to a PNom ratio (Parray/Pinv) = 1, which is a reasonable minimum. Usual Pnom ratios are of the order of 1.15 to 1.25 (see below). The upper limit is not clear, probably the specified available area. I have to check in the program. But the second warning “The inverter power is slightly oversized” is quite justified. Please see - the help "Project design > Grid-connected system definition > Inverter / Array sizing" (directly accessed by the little orange button right top of the box), - our FAQ on this forum What is the basic concept of Inverter sizing ?, - The tool "Show sizing" just next to your message. Now for the use of special inverters of the SMA series "tripower", please see How to use the inverters with very different MPPT inputs (Tripower of SMA) ?.

You have 2 possibilities: - either use the dedicated tools in the main menu "Files" / "Export whole projects" and /"Import whole projects" and "Export/Import database components". (see How to export/import projects or database components), - or copying the whole working directory (see Where are stored my working data of PVsyst ?).

>> Tools >> Solar tool box >> Tables / graphs of solar parameters >> is only a accessory tool, it is not the heart of thre program. And indeed I did not include the tracking calculations in this (very old) tool. I plan to do that in a "medium" future. For definig tracking systems, you have to define a full system, i.e. option "Project design". In the calculation version, button "Orientation", you have the opportunity of defining various kinds of tracking systems. You can also define tracking systems in the 3D editor, button "Near shadings". Now I don't understand your request: if you want irradiance "normal to the plane" you can't have a fixed tilt of 50°: at a given time, the plane tilt will be 90° - sun's height.

In PVsyst the time labels always correspomd to the beginning of the interval. See the FAQ on this forum How is labelled the time step in PVsyst ?

In PVsyst, the meteo data may be specified in 2 kinds: - SIT files, which define the location of a site (Site name, Country, Latitude, Longitude, Altitude, Time zone). In addition the Site includes meteo values (at least Global horizontal irradiation and temperature) in monthly values. - MET files, which define meteo data in hourly values. NB: The MET file includes an internal SIT object for the determination of the location. Now within a project, you begin by choosing a location, i.e. a site in the database. Then you choose a MET file for the hourly meteo data which will be used in the simulation. You can choose this MET file in your MET database if you avail of a specific meteo already imported from a given meteo source. If not, PVsyst will automatically create a synthetic file based on the monthly data of your project's site. The montly values of the SIT file of the project are not used in the simulation process. But they are important for 2 reasons: - If you don't avail of meteo hourly data, they will be used for the Synthetic generation, - Although not necessarily identical to your MET data, these values should be existing and realistic as they are used in the sizing tools like the orientation optimization or the histogram for the sizing of the inverter (i.e. only used for decision makings during the sizing process).

The thermal behaviour of the field - which strongly influences the electrical performances - is determined by an energy balance between cell's heating up due to incident irradiance and ambient temperature: U · (Tcell - Tamb) = Alpha · Ginc · (1 - Effic) where Alpha is the absorption coefficient of solar irradiation (or identically 1 - Reflexion), and Effic is the PV efficiency, i.e. represents the electrical energy removed from the module. The usual value of the Absorption coefficient Alpha is 0.9. It is eventually modifiable in the PV module definition dialog. When possible, the PV efficiency is calculated according to the operating conditions of the module. Otherwise it is taken as 10%. The thermal behaviour is characterised by a thermal loss factor designed here by U-value (formerly called K-value), which can be split into a constant component Uc and a factor proportional to the wind velocity Uv : U = Uc + Uv · v (U in [W/m²·k], v = wind velocity in [m/s]). These factors depend on the mounting mode of the modules (sheds, roofing, facade, etc...). As we don't have reliable coefficients for wind velocity (and the wind velocity is often not well assessed in hourly values), PVsyst proposes as default to take a fixed U-value (i.e. assuming a constant wind velocity). For free circulation around the modules, our measurements show a value of 29 W/m²K. This coefficient refers to both faces, i.e. twice the area of the module. If the module is thermally insulated on the back, the second face doesn't contribute, and we have half this value, i.e. 15 W/m²K. Intermediate cases with air circulation duct may have values from 18 to 25 W/m². We don't avail of assessed measurements. NB: Some people use the NOCT concept. You can get an equivalence between U factor and NOCT values by inputting the NOCT conditions in the above thermal balance. But to my mind this is confusing and should not be used. Measurement of Uc and Uv The measurement of these parameters is possible by using long-term data recorded on-site (several weeks or months). You should avail of measurements of the Module temperature, the ambient temperature, the irradiance on the PV plane, and eventually the wind velocity. You can plot the (Tarray-Tamb) difference as a function of the irradiance (may be negative during night by clear conditions, due to IR deficit with sky) Then you can extract the parameters from a bi-linear fit (with wind) or simple linear fit (without wind, Uv=0). PV array temperature measurement: According to our experience, the PV module (cell) temperature may be recorded using a temperature sensor (thermocouple or PT100) glued or fixed with thermal grease on the rear side of the PV module, with a 1 cm thick polystyrene cover of 7 x 7 cm2. The size of the thermal insulation is a compromise between a good insulation of the sensor with respect to external (in order that the heat flux is negligible), and the local perturbation of the local PV module temperature due to this insulation. This mounting mode optimization results from a diploma at the University of Geneva, where we had a special module with a thermocouple on the cell, included in the encapsulation, so that we had a reference for performing differential measurements. NB: Ensure a good mechanical "external" fixation of the polystyrene piece (a simple adhesive tape is usually not sufficient at medium or long term). NB: Some people propose to add 3°C to the rear-side measured temperature for taking into account the temperature drop due to a heat flux from the Cell to the sensor. This would be valid if the sensor is not recovered by an insulation. In this case we don't know what is really measured by the sensor: an intermediate temperature highly depending on the ratio between the heat resistance in the rear sheet, and the sensor with respect to the ambient. Moreover the difference between cell and sensor is obviously proportional to the heat flux, i.e. the (TArray-TAmb) temperature. Therefore I can't understand this fixed correction of 3°C. Please see the help about this subject ("Project design > Array losses in PVsyst > Array Thermal losses").

Some practicians - and most of PV module's catalogues - usually specify the NOCT coefficient (Normalized Operating Cell Temperature), which is defined in IEC 61836: it is the temperature attained by a PV module in specific conditions (800 W/m², T=20°C and wind speed=1 m/s), and this for a non-operating situation (open circuit), for a "nude" rack-mounted module with free air ventilation. Please don't use the NOCT approach, which is very confusing, but define a Heat Loss Factore U [W/m²K] for your PVsyst simulations. For me the NOCT value for a module is only dependent (slightly) on the cover (glass) and back kind of the module (glass, plastic), and is useless for the module temperature evaluation. This is the reason why I did not include it in the PVsyst parameters. As a confirmation of this, a team of the NREL in the USA measured side-by-side, at sun during several days, 3 modules with resp. 42.4°C, 49.7°C and 52.3°C NOCT manufacturer's values, and these 3 modules showed exactly the same temperature within 0.3°C ! On the other hand, the NOCT doesn't include any information about the mounting mode (free ventilated, integrated and insulated, etc). It is always given for a "nude" module. Moreover is is defined for open-circuit conditions, i.e. not-operating conditions; this doesn't make sense as the produced energy affects the energy balance. If you apply the U-value thermal balance equation to the NOCT conditions, you will obtain an equivalence between the U-factor and the NOCT for specific conditions. But this doesn't make much sense, and is very difficult to interpret. Please completely forget the NOCT approach !!!