André Mermoud

In the version 5, the default transposition model was the Hay model. In the version 6, the default has been changed to the Perez model, as according a recent study it appears as slightly better. See in the FAQ, the differences in yield between the version 6 and the version 5.

It has perhaps been removed by mistake, I don't know. I will reintroduce it for a next version.

This option is to be used when you define a "Module Layout" configuration. If such a configuration is not defined, there is nothing to calculate, and this option should not be activated. It is indeed a mistake in the present version, I will manage for desabling this option.

You can simply try it by yourself, using PVsyst... And tell us your conclusions if you have interesting ones.

It is not possible directly in PVsyst (and probably in any other software). PVsyst is based on the Diffuse part. The DNI is computed in hourly values from the global and the diffuse. The DNI is defined on a monthly basis only as a sum of these hourly values. Now the generation of hourly values is performed using the synthetic generation model. This complex model is based on the Horizontal global (and possibly the specified Diffuse). We don't have any model for generating hourly values from monthly DNI data.

The direct import of the helioclim3 monthly data is not implemented in PVsyst in the present time. Some years ago Helioclim proposed monthly data (HC1) for several years, and I had developed the importing tool for these data. But the data format has changed with the new version HC3, and I did not yet write the updated tool in PVsyst. However you can easily create a "Site" in PVsyst using these monthly data: please use "Database" / "Geographical sites" / "New", and fill all the required fields in the dialog. You can directly "Copy" the 12 monthly values of the Global Horizontal (or temperature) from your ECXCEL file. The simulation requires at least the Global Horizontal and Ambient temperature data. All other values are optional.

The winter/summer time (named DST - Daily Saving Time in the US) affects the simulation during the year. It doesn't have any impact on the simulation results. Except for the financial revenues if you have specific tariffs for specific legal hours: in this case you have to do your financial balance by yourself (in EXCEL), using the CSV hourly output file. The DST is in principle defined in the Meteo data file. However PVsyst (as many solar software and meteo data sources) doesn't take it into account, and renormalizes all the data in the same time (usually the winter time). When you import an external meteo file which takes the DST into account, PVsyst corrects the values for getting homogeneous time definitions along the year.

In your workspace you only have the components that you have created or modified by yourself. The full database of PVsyst is in files stored in the c:\program Files\ directory. You don't have access to them and you normally don't need them. If you want to export a file of the database, you have to open it, and save it under another file name.

In the version 5, the default transposition model is the Hay model. In the version 6, it is the Perez model. Now these are models (with their uncertainties), not the reality ! The Perez model is known for giving slightly higher transposed values (by 0 .. 2% according to climates, plane tilts, etc). However please observe that these optima are very broad: a difference of some few degrees (with the same model) represent a very little irradiation difference.

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.