André Mermoud

In PVsyst this is evaluated by applying the one-diode model. You have some formulas for computing the Pmpp with linear derates from the STC as function of temperature and irradiance, but to my knowledge not each point of the full I/V curve (or described in very specific papers). However these are approximations.

This means that your data are not correct. It could be a problem of units, or more probably the calibration of the solarimeter.

The development of a floating system is very similar to a normal terrestrial systems. We can identify two topics for which the treatment of floating systems may be slightly different: Temperature of the modules Unfortunately we don't have any information nor measurements about the temperature on the water. Due to the evaporation, the ambient temperature could eventually be slightly lower than the temperature measured on the ground area using the "Meteo standard" measurment (i.e. measure in a shelted box, at 2m above a ground of grass of at least 100 m2). Or the U-value could be slightly different. The module temperature may be strongly dependent on the technology of the supports: are the modules directly "seein" the water, or on a platform? etc... The only reliable way to determine these conditions would be to measure them on-site: see How is evaluated the Module temperature during simulation? NB: If you get such measured data, we (and the PV community) would be very interested to get the results ! Now in the simulation, if you want to decrease the operating array temperature you have to increase the Uc value in "Detailed Losses > Thermal Parameter". There is a limit to this parameter (50 W/m²K). If really necessary, you can increase it in the "Hidden Parameters", topic "System design parameters", item "Heat loss factor Maximum value". If necessary, we could indeed modify the thermal model for this specific situation, where the backside is "seiing" the water: perhaps develop a model involving the water temperature. We think about such a model, but we don't have any experimental data for establishing or assessing it in the present time. Remember that for crystalline modules, a decrease of 10 °C of the array temperature will increase the yield by about 3.5% to 4%. Albedo of a water surface The water absorbs a big part of the incident light. As amazing as it sounds, the albedo of the water is very low, some people propose about 0.06. Only when the sun is very low on the horizon, there is an important reflexion, but this is specular and its duration is rather short. By the way for a big installation in rows, the albedo is not significant as it is only "seen" by the first row. The shading factor on the albedo for the whole plant is (n-1)/n, where n is the number of rows. As an example a system of 100 rows will have a shading factor of 99%, i.e. it will "see" only 1% of the albedo contribution. Therefore the definition of the albedo parameter has no real importance. Tracking systems If your system is a floating disc following the azimuth of the sun during the day, you should use the option "Tracking with Vertical axis". From the future version 7.3, it will be possible to define a backtracking strategy for this situation.

These values are a result of the Clear day model. This model only depends on the geographic coordinates and the air mass, i.e. the solar geometry. Therefore you can calculate the values for any time.

The exposition to the sun is sufficient for enabling the LID degradation. However ths doesn't have any importance, as this concern the very beginning of the PV plant production, and therefoer a completely negligible amount of energy.

This is quite different: - the albedo mentioned in the project concerns the full "far" area in front of your installation. It is used in the transposition model. - The albedo of the Bifacial model describes the reflexion of the ground just under your PVsystem (roof, grass, rocks, painting, etc)

Since the version 6.60, we have implemented a model for the simulation of bi-facial systems. This model is for the moment restricted to shed-like systems, with the hypothesis of "unlimited sheds". We will develop models for other configurations later on. This tool becomes available in the software as soon as you choose a bi-facial PV module. In PVsyst, Bi-facial PV modules are characterized by one only parameter, the bifaciality factor, which is the ratio of the STC efficiency of the rear side with respect to the front side. For such a model, we have to evaluate the irradiance available on the ground, a reflexion parameter named "albedo", and the reemission to the back side of the PV array. This evaluation is done numerically, based on 2 basic hypothesis: the diffuse irradiance is isotropic, and the re-emission from a ground point is also isotropic. From V 6.64, the diffuse irradiance from sky on the rear side will also be taken into account. However this is a little contribution with reasonable tilts (less than 20°). Irradiance on the ground The irradiance available on the ground is calculated taking the shading of the PV system into account: - the beam component between the rows is obviously dependent on the sun's position, - for each point of the ground, the diffuse effectively reaching this point is calculated using the isotropy hypothesis of the diffuse (view factor of the sky). The diffuse distribution on the ground is independent on the sun's position. It is only related to the geometry of the system. Irradiance on the rear side The irradiance on each ground point is reemitted in all directions according to the Albedo factor. Again, using the isotropy hypothesis of the re-emission , we can calculate the fraction which is re-emitted to the PV array, and the quantity lost to the sky (view factor). The luminous energy available for each ground point is the sum of the diffuse component, only dependent on the geometry, and the beam component when this point is illuminated by the beam (depending on the sun position). We should emphasize here that the ground irradiance and reemission is dependent on the position below the array. NB: We have recently found a conceptual error in the Bi-facial model. Up to the V 6.63, we had considered the exchange between the ground and the rear side of the PV modules as an energy, when it is indeed an irradiance. This means that the reemitted energy to the rear side of the collectors should be renormalized by the involved surfaces. That is, the rear side irradiance should be multiplied by Pitch/Coll. width (1/GCR), which gives a factor of 2 or more! This has been corrected in the version 6.64. We have indeed: Energy(rear) = Albedo * ViewFactor * Energy(Ground) i.e. Irrad(Rear) * Coll area = Albedo * ViewFactor * Irrad(Ground) * GroundArea => Irrad(Rear) = Albedo * ViewFactor * Irrad(Ground) * GroundArea / CollArea Therefore Please use the version 6.64 and forget the results of the previous versions 6.60 .. 6.63 ! Other perturbations We should take several perturbations of this simple model into account: - a shading loss, which is characterized by a simple factor (could be the structures, the eventual junction box if on the rear side, etc ) - the rear side irradiance is not uniform, there is therefore a mismatch between sub-modules, leading to electrical losses. PVsyst doesn't have any reliable value to propose for this parameter in the present time, - The PV module may eventuially have some transparency (spacing between the cells - or even the modules): this will contribute to the ground irradiance. Now PVsyst provides a calculation framework - established with simple and well-defined hypothesis - which may be applied all over the year. This is a reasonable physical model, but we don't have any validation. Comparison with other studies However comparisons with existing experimental systems and publications is very difficult as: - Most of the experimental setups are made of one or two modules, above an "illimited" ground area. Therefore receving light from a big illuminated environment. The model in PVsyst supposes a realistic installation with Unlimited sheds, i.e. usual rows spacing and no additional albedo contribution from the edges of the system. - The results are often available for some specific conditions, not over a full year measurement. - The albedo conditions may be not realistic with respect to real systems (specific surfaces, variability when wet, ageing, etc).

PVsyst proposes a model, established according to well-specified hypothesis, either for the irradiance availability on the ground and for the Form factor. It gives detailed results about the ground availability and the rear side irradiance, along the whole year according to your meteo data. However we don't have any validation. In fact we didn't got any results registered in good conditions with a realistic PV system up to now. Now most of people studying this subject work with one or 2 modules on an "illimited" reflective area. This is the case of both papers you are referencing. Even if the simulation of the Universities of Konstanz and al. are done with 5 rows, you can observe that: - the extreme modules behave better due to the larger"seen" reflective area (on 4 edges) - the chosen inter-row is very large (if modules are 1 m wide, the "pitch" of PVsyst is 1 * cos(25°) + 2.5 m = 3.4 m, so that the GCR is 0.29. - the chosen albedo of 0.5 seems irrealistic in real conditions. Their only measurements are for one pair of module only, at 1.2 m altitude. They don't tell us how they have measured the albedo coefficient taken in the model, therefore it is difficult to have a full confidence in their validation. The PVsyst model tries to represents a realistic PV system, i.e. with the "unlimited sheds" hypothesis. Please see the fig 5 of the publication: with a reasonable (usual pitch (1m between rows, i.e. a GCR of 0.52), the gain is of the order of 8%, not so far from the results of PVsyst before shading and mismatch losses.

You are certainly using a version < 6.40, and trying to read a file (PV module, inverter) created by a version >=6.40.

This is because you have not defined the "rectangles" representing a string correctly. You have defined one rectangle as one submodule. In the option "According to module strings", one rectangle should correspond to one full string.

We could indeed increase the number of decimals here (and in many other places). This would make the reading of the report more heavy, without a significantly better accuracy. For your example, the "reading error" represents perhaps 10% of your wiring resistance loss (because it is very low, probably not realistic), but 0.05% of the system yield ! I doubt that your Rwiring evaluation is much better than this value.

Yes of course. The simulation of PVsyst is based on horizontal meteo data, and evaluates the POA using transposition models. An additional improvement for the accuracy would be to measure also the diffuse component on the horizontal plane.

It is indeed the definition of the Backtracking strategy to avoid mutual shadings. It does that by adjusting the plane tilt (phi angle) according to the sun's position. If you don't have near shadings you don't have electrical shading losses of course. Now I don't know how you evaluate the plane tilt during operation: this will highly depend on the sun's position. However if you construct the same system with fixed tilt, you should have exactly the same shading situation for the same plane tilt and same sun's position.

The nominal power of your inverters may be up to 1155 kW if the temperature around the inverter is less than 35°C. Please explain in detail how you observe an increase of 15 kW with respect to this value.

Importing Sketchup or AutoCAD files (in .DAE or .3DS formats) is now possible since the version 6.60. See the help "Project design > Shadings > Near Shadings: Import > Sketchup and other CAD software"

PVsyst is oriented towards PV systems. It doesn't involve a complex building model for the evaluation of the PV modules temperature, which would require a lot of additional paramewter. However you can import the Array (cell) Temperature in hourly values along with the Meteo data (CSV hourly file). You can therefore create a representative temperature time series using your own models - synchronized with your weather data - in MS EXCEL, for using during the simulation.

With Helios3D scenes on hills, the baseline slope induces an orientation distribution of each table. In this case PVsyst uses an average orientation. See our FAQ "With my installation on a terrain, I have multiple orientations".

In the present time, PVsyst can work with one average orientation. We are preparing (for very soon) the opportunity of defining several average orientations, with tools for the attribution of tables to one or the other orientation. Now please observe that the orientation (and its averaging) only affects the transposition result. A reasonable mis-orientation or dispersion around an average will not have a too big impact on the accuracy. The mutual shadings calculations (shading factors) are only based on the system geometrical configuration. They are taken correctly into account, even with orientation dispersions.

This would require a specific tool for each source of Meteo data, which are all different. For getting many of them, a manual manipulation (on the web) is often necessary. Very few offer an API for a direct import, and the use of such API is not yet implemented in PVsyst.

No sorry. There is no mobile license for PVsyst.

The wiring losses are basically calculated using the resistance Rwiring, which is the basic parameter used in the simulation (and stored as a parameters). Now PVsyst defines an equivalent value expressed as the percentage of the loss under STC conditions (i.e. PNom). This value is more convenient for a first approach of your system development, as the default value is well understandable and doesn't depend on the system nominal power. However in the last steps of your PVsyst system evaluation, you should calculate this Rwiring explicitly according to your real wiring conditions. NB: the specified percentage as function of the STC power will not be your final energy loss. See our FAQ Why the losses in the results are different than those specified ?

Yes, the principle is the same for PNom values different due to the temperature.

The "linear" shading loss is the result when using the first table. The second table is used for computing the Electrical loss (accounted in the Array losses), which results basically of a difference between the two tables. The Module layout tool - which is closely related to the inverter behavior - is indeed not available for Stand-alone systems in the present time.

In PVsyst, the shading losses are the result of a detailed calculation, involving your system configuration and the irradiance distribution. You cannot explicitly specify monthly values of course.

I don't understand what you are doing. A negative pitch doesn't make sense in the calculations. It is so unusual that we even not thought to forbid it in our error messages. By the way, you cannot use the backtracking strategy with a misalignment of the trackers. See the FAQ How is defined the Tracking Axis azimuth ?