André Mermoud

This limitation is a protection against bad definitions (especially for the number of cells in series). It prevents the calculation of the model. You can change this limit in the hidden parameters, topic "PV modules".

I have corrected the issue with Polygonal fields for the next version 6.11.

You can get a plot of the clipped output in the results, using button "Hourly graphs". You can get here plots for any of the variables accumulated in hourly values during the simulation, including of course E_Grid. However PVsyst doesn't provide both curves at different powers in the same simulation. For this you should perform 2 different simulations with different installed powers. You can create CSV files of hourly data, for both simulations. Then you can analyse (merge) these files, and do the plots in EXCEL

In the 3D shadings part, the areas are first defined regardless the module sizes. I plan to develop a tool for defining these sizes in terms of module sizes for a future version. Now the Ground cover ratio is defined as the area of the modules themselves to the occupated ground area. This indicator doesn't involve the projection of the modules on the ground. Roughly for sheds or trackers, the GCR is computed as the sheds or trackers active width, divided by the pitch between rows (the pich is base-to-base, or center-to-center). This rough estimation doesn't take into account the surroundings of the array, nor the eventual space between arrays if there are several distinct arrays.

For creating a new site in monthly values: In "DataBases" / "Geographical Sites" / "New": - You define the coordinates of the site, site name, country, etc (you can do that using the Google map), - On the first page you choose the data source (Meteonorm or Nasa-SSE), and you push the button "Import". This loads the monthly values (second page). - PVsyst will prompt you for saving the site when you will exit by OK.

This error message is a generic one, issued by DELPHI in many situations. This cannot help understanding the problem without further information. If you report such a problem, please provide: - A screencopy (full screen) of the error message - The LOG files, that you can get from the main menu "Files" / "WorkSpace", button "Export Logs". (or in versions 5: "Files" / "Export Log Files"). - The description of the situation when encountering the error, in which situation you are, what you are doing, - Explain if the error comes systematically or just for some projects.

No, it is not possible in the present time. We will think about this proposition. However the part "Detailed computation" is only a quick tool for the estimation of wiring resistances. The parameter waited by the simulation is only the equivalent resistance of the wires of the circuit. For complex circuits, you can evaluate this global resistance by your own calculations, and just put the resulting resistance as parameter.

When this message is shown, you have an error message in red on the top right of the main page "Basic data", telling what is wrong or not understood by PVsyst in your definitions. Please take this warning into account.

No worries. PVsyst works quite well with 64 bits OS !

No sorry. PVsyst works with one-hour time steps. This is a fundamental choice, concerning namely the basic data storage. Managing sub-hourly values would represent a very deep development in PVsyst, which is not planned at the moment.

I don't know. To my knowing the Array temperature is imported correctly when using the option "Array temperature" in the format protocol. Please send me the source file, the site file and your format *.MEF, and I will have a look on your import. The meteo monthly data of the reference site don't interfere in any way with the reading of your hourly values.

This bug has been introduced recently ba accident, sorry. I have corrected it for the next version 6.11, to be released before end of August.

I have indeed forgotten implementing this in the module's specifications. This is on my to-do list and will be done for a next version (not necessarily the next one...)

Some few MW is really a limit for the version 5, because the calculation time goes with the squarte of the number of elelmets. In the version 6, the shading factor calculations have been optimized. For big systems the time is improved by a factor of 10 or more.

This is fully expalined in the help "Project design > Array and system losses > External transformer losses". You can also see our FAQ How to determine the parameters for External Transfo Losses ?

In some big PV installations (in the MWp range), the transformer is not part of the inverter, but an external device directly connected to the MV grid. The main losses associated with the transformer are: - The iron losses (mostly due to hysteresis and eddy currents in the core) are proportional to the square of the core flux, i.e. to the square of the voltage. As we have a constant grid voltage, this is considered as a constant loss. PVsyst proposes a default value of 0.1% of the nominal power. - The ohmic losses, often named copper losses, either in the primary and in the secondary windings. These may be represented by an equivalent resistance, and the loss will be computed as R * I² during the simulation. Therefore the yearly resistive loss will always be lower (in percentage) than the nominal loss at STC. NB: The iron loss remains active and constant during the whole connecting time, and may represent a significant energy loss.This appears as negative E_Grid system yield during the night. Therefore it may be economically profitable to foresee a switch for disconnecting the transformer from the grid during night. The option "Night disconnect" is available for the simulation. Parameter determination The transformer manufacturer usually specifies on the datasheets: - a nominal power PNomTrf - a global loss under this nominal power PGlobLossTrf [kW] or FGlobLossTrf [%] = PGlobLossTrf / PNomTrf - an iron loss, i.e. global loss at null power PIronLssTrf [kW] or FIronLssTrf [%] . = PIronLssTrf / PNomTrf => we can deduce the resistive loss as the difference PResLssTrf = (PGlobLossTrf - PIronLssTrf), which behaves as the square of the PoperTrf. In PVsyst the transformer losses are specified as percentages of the system output Power when running at STC, named PnomAC (appearing as "Pac" on the Ohmin losses dialog). NB: this PnomAC = PnomPV (STC) * Inverter efficiency at PnomPV. This is a definition for the calculations. This should be considered as not affected by the inverter or grid injection limitations. Passing to the PVsyst parameters, referenced to PnomAC: - PIronLss(PVsyst) = PIronLssTrf [kW]. - FIronLss(PVsyst) = PIronLssTrf [kW] / PnomAC = FIronLssTrf * PNomTrf / PNomAC - PResLss(PVsyst) = PResLssTrf * PNomAC ² / PNomTrf ² - FResLss(PVsyst) = PResLss(PVsyst) / PnomAC = FResLssTrf * PNomAC / PNomTr, i.e. the opposite behaviour !!! (the higher the PnomAC, the higher the resistive loss factor, but the lower the Iron loss factor). NB: If there is a second HV transformer in the circuit, you should calculate the loss percentages in the same way, and add them to the MV transfo contribution. As an example: Transformer parameters from the datasheets: - PNomTrf = 1.5 MW - PIronLssTrf = 1,5 kW (i.e. 0.1% of PNomTrf) - PGloblossTrf = 16.5 kW (under nominal power PnomTrf) => The resistive loss is PGloblossTrf - PIronLssTrf = 15 kW (i.e. 1.5% of PnomTrf). In PVsyst, if we have a PV system of 1.05 MWp with an inverter efficiency = 95% @PNom => Pnomac = 1 MW (the Pnomac value appears as "Pac" on the AC circuit inverter loss dialog). Applying the previous expressions: - PIronLss(PVsyst) = 1.5 kW - FIronLss(PVsyst) = 1.5 kW / 1 MW = 0.15% - PResLss(PVsyst) = 15 kW * (1 MW / 1.5 MW)² = 15 kW * 0.444 = 6.66 kW - FResLss(PVsyst) = 6.66 kW / 1 MW = 0.66% The values 0.15% and 0.66% are those to be introduced in PVsyst.

This loss corresponds to the iron loss of the transformer, it is proportionnal to the voltage applied to the secondary. It occurs during the full time, when the transformer is connected to the High Voltage grid. Now if you have a switch between the output of the inverter and the high-voltage line, which is open during night, you can check this option. Otherwise you shouldn't of course.

Nobody cannot give any explanation if you don't mention the full parameters and data. You don't mention the GlobInc irradiation value of your meteo data. The best tool for analysing such results is to have a look on the Loss diagram.

You have to change the parameter "Limit Overload Loss for Design". In the version 5, in the Hidden parameters "Detailed Simulation Verification Conditions". In the version 6, in the Project's parameters, button "Albedo-Settings". In the FAQ, please see "Can I define a system with very oversized Inverter ? "

I have carefully checked the program and everything seems to be OK. For a tilted single axis system, I have analysed a clear day and a cloudy one, and everything is quite coherent. It is interesting to observe that the albedo loss is of the same order of magnitude than the loss on diffuse, either on the clear day, and in the monthly results. Clear day diffuse and albedo losses for Normal tracking and backtracking systems I also have analysed the monthly and yearly values, and I observe that as expected, the Shading losses on diffuse and albedo, for normal system, are higher than the ones with backrracking. I don't see a higher loss with backtracking, as reported by other users. If you have such data with single-axis projects, please send me the full project. NB: for dual-axis systems, there are several backtracking strategies possible. Depending namely on the nechanical tracking system. In PVsyst only one has been developed in the present time: keeping the tilt according to the sun's height, the backtracking is applied to the azimuth. In this mode (probably far from being optimal) the diffuse and albedo losses may be very high, and there is no reason that they are lower than with not-backtracking systems. Global results for both tracking options. Detailed contributions of all components: Beam, Diffuse and Albedo.

You are right. Diffuse losses over 1.5 to 2% seem quite unrealistic (I did only observe 1% to 1.5% during my development). And getting higher losses with backtracking is not logical. I will carefully check my calculation.

I have corrected this for the version 6.11.

No sorry, in the present time the use of heterogeneous fileds is not possible with stand-alone systems. I intend to deeply modernize the Stand-alone systems management during the next months. I will of course study this possibility.

You are right. The horizon shading is a very difficult problem, also for the interpretation of the results. In PVsyst it is calculated explicitely, and is included in the PR. With measured data, it is not. What is the official definition of the in the norm IEC EN 61724 ? I'm not sure, but I think this uncertainty is not addressed. Please see the FAQ How is treated the Horizon contribution in Meteo data?.

The new version 6.11 should be released within about 2-3 weeks. However with this new development, simulation the backtracking without 3D scene is no more advised, since we found that the shadings on the diffuse are not negligible.