André Mermoud

The Irradiance units are not correct. However it is not possible to import POA data in daily values. The retro-transposition model only works on an hourly basis.

In PVsyst, an horizon line below 2° is not taken into account. By the way this would not be significant, especially in sub-tropical climates.

The "Availability" parameter defines periods of Failure (which may be generated randomly if desired) They could be defined for example by night, therefore leading to no loss. Please check that in your "Detailed Losses" the failure periods really occur during significant production times.

This error has probably been solved in the version 6.41. Please try. If it doesn't work, please send your whole project to Support@pvsyst.com, using "Files > Export project" in the main menu

Yes, the format for importing Hourly Load data has been changed. You have now to prepare a file in the "Standard PVsyst format" as described in the help "Project design > User's needs ("load") > Load profile: ASCII file definition". Sorry for the inconvenience, it was necessary for a modernization of the PVsyst Load management. This format will also be useful for importing other parameters in Hourly values in future versions. You have a template of this file in "c:\ Program Files (x86) \ PVsyst6.x.x \ DataRO \ PVsyst640_Data \ UserData\ Hourly_Parameter_Template.CSV" (or ... \ SubHourly_Parameter_Template.CSV). Your own data file should be placed in your workspace \ PVsyst640_Data \ UserHourlyParams \ NB: Thank you for your example file: I tried it and it works correctly (see the graphs after importing). Just the file Preview does not work correctly: it doesn't recognize the comma as separator. I will correct this.

I just tried and everything works correctly. However in the version 6.40, the Variables to be written were not well recorded on the Calculation Version (VCi) file. So that when reopening a VCi file of the version 6.40, when outputtting an ASCII file you have to explicitely redefine the variables to be written before simulation.

No, we don't organize training sessions elsewhere than in our offices at Geneva (except sometimes for the team of a company).

The simulation (in hourly steps) involves about 40-50 variables, calculated from different models (Transposition, Shadings,IAM, PV module modelling, Losses, inverter behavior, etc). These variables may be stored on an CSV file for further analysis during the simulation.

You have defined a number of PV module in the "System" part. PVsyst checks that you have defined sufficient room in the 3D construction for installing all these modules.

Yes the "normal" simulation is valid for the first year of operation. Now if you want to take a long-term degradation into account (of the order of -0.5% to -1%/year), you can put this additional loss in the "Module Quality Loss" factor. See our FAQ How to define the "Module Quality Loss" parameter ?

The license name is indeed not critical. In your case the problem is that the "Local number" read on the target computer is not correct. Please open PVsyst (V5.xx) on the target computer, and carefully read the "Local number" (menu "License > Status and Activation"). Then you can come back to this licensed computer, copy this "Local number" here, and this will give your user's code for the target computer.

If you cannot find your original invoice, you have to contact admin@pvsyst.com.

The license name is indeed not critical. In your case the problem is that the "Local number" read on the target computer is not correct. Please open PVsyst (V5.xx) on the target computer, and carefully read the "Local number" (menu "License > Status and Activation").

When defining the "User's needs", you have an option for importing load hourly values as a CSV file. Please choose the option "Load values read on ASCII file", anf follow the procedure described in the help.

The Module layout tool may only be used after defining a valid 3D shading scene. As indicated by its name, the module area is the area of the modules themselves. I.e. the area of one module, times the number of modules. The ground area occupied by your array (or system) is not evaluated in PVsyst. It depends on your system implementation.

You define the losses in the "Detailed losses" dialog. PVsyst proposes default values (for your first simulations). And for several of them you have a detailed Help for understanding their meaning. However most of the values are closely related to the situation and the conditions of your project. You have to evaluate them by yourself.

Sorry, the option for creating "PV tables (one ore more rectangles)" doesn' exist in the main menu. So I don't know what you did. When you exit the editor by the red cross (top right), this means that you exit by "Cancel" (it is a Windows standard). Therefore you loose your modifications. However in the 3D editor, there is a warning inviting you to keep your modifications anyway. The normal way for exiting the 3D editor is to use the main menu "File > Close". Now if you had saved your scene on a *.SHD file, you should be able to read it.

In the version 6.40, we have implemented PVsyst data files as text files. However this is for the internal use of PVsyst. It is not meant for manipulating the files. These files are written with high internal coherency ensured by the program. If you modify them the results are not guaranteed. Therefore you don't need to know the signification of each item. We don't intend to give a description of the hundreds of parameters and their organization.

This problem will be fixed in the next version 6.41.

When the diffuse is available on an hourly file, PVsyst will always use it. This is the case for your Meteonorm external file. If a dataset is imported from Meteonorm (internal to PVsyst), the diffuse is also calculated by Meteonorm. Now there is a mistake in the denomination in the PVsyst report: the model for diffuse used by Meteonorm is indeed the Perez model, not the Erbs model. I just got the confirmation from Jan Remund last week. We will correct that in the next version. However I don't see well how the fact to know which model is used could have so "huge" effects on the shading calculations. The effect of diffuse is more important on the transposition.

This is typically a problem of time shift between the recording time of your data and the time of PVsyst (i.e. when the solar geometry is calculated). Please see the help In V 6.40: "Meteo Database > Notes on Meteo > Meteonote9_Time shift in meteo files" In V <= 6.39: "Meteorological Data > Hourly Meteorological Data > Time shift"

Yes, the denomination of the data source "US TMY3 (or TMY2)" has been changed into "NREL National Solar Radiation Dababase" in the version 6.40. We will revert to the old denomination in the next version 6.41.

Yes your reasoning is right: the soiling loss is specified in terms of percentage of the yield. Therefore if low irradiance in winter, the loss will be lower in absolute value. For your monthly analysis you have to consider the absolute losses, not the percentages.

The cell's temperature at sun is established using a little energy balance model. The parameters of this model (U-values, possibly accoding to the wind velocity) are of your responsibility, and defined in the "Detailed Losses". The model is explained in the help "Project design > Array and System losses > Array thermal losses".

When the inverter is able to produce reactive power (i.e. able to produce a phase shift), the Nominal Power (PNom) may concern - either a limitation in Active (real) energy, expressed as [kWh] - or a limitation in Apparent energy, expressed as [kVA]. This limitation is rather usual as it is equivalent to an output current limitation. This is a a property of the inverter, therefore a choice in the definition parameters.