Bruno Wittmer

With PVsyst V6.25 the handling of large and complex 3D scenes has been improved. The loading and saving of the different variants has been made faster. The editing of the 3D scene is much smoother. This makes the handling of large projects now much easier.

The files with meteorological data (.MET extension) are associated to specific sites. When you import the data, you specify the site, to which this file will be linked. When you want to use the imported file, you have to make sure that you first select the correct site, then the .MET file will show up in the dropdown menu. Note that you can associate more than one .MET file to the same site (for example to compare different data sources or different years). PVsyst will always compare the geographical coordinates of the meteorological data file (.MET) and the site for which you want to use it, and issue a warning, if they are too far away from each other.

For some of the crosschecks in PVsyst, two angles are considered to be the same, if they differ by 1° or less. For projects with multiple orientations that have small differences (<= 1°) between each other, this may lead to inconsistent behaviour, when Tilt and Azimuth are matched between the 'Orientation' dialog and the 3D scene. The problem is being adressed and a solution is envisaged for one of the next releases. To work around the problem, sub-arrays with tilt or azimuth differences equal or smaller than 1°, should be gathered in one single sub-array with the same average orientation. Note, that in the 3D scene, fractional angles will be rounded to integer values for displaying and crosschecking. Internally the fractional values are conserved.

You have to make sure, that the axis tilt is the same in the 'Orientation' Dialog as for the trackers in the 3D scene definition. PVsyst will crosscheck those two values and give an error message, if they do not match, but only differences larger than 1° are considered errors. The report will show you the value defined in the 'Orientation' Dialog, and this is also the value used in the simulation. So you should change the axis Tilt to 1° also in the 'Orientation', to get the expected result.

PVsyst does not foresee to use decimal commas. You will need to set set decimal dots in Windows or in Excel: For Windows 8 you find the setting in: 'Region -> Formats -> additional Parameters -> Numbers' . You need to restart Excel for this to take effect.In Excel you find the setting in 'Options -> Advanced -> Editing Options' After importing the file you can change back to decimal commas.

Hi Amir, the IAM is just a factor that is applied according to the incident angle. The details are given in the online help under 'Project Design -> Array and system losses -> Array incidence loss (IAM)'. You can find this page also on the web. The ASHRAE model used in PVsyst is a simplification, but should give good results in most cases. The transmittance of the glass cover is only relevant for multiple reflections, which contribute little to the overall loss estimation. The non-perfect transmittance is neglected by the model. In the attached picture you can see as an example the comparison between the ASHRAE model, a calculation with double reflection using Fresnel's law and the measurement from the manufacturer. If a better approximation than ASHRAE is known for your system, you can define a customized IAM profile in the dialog 'Detailed Losses', tab 'IAM losses'. The definition of the IAM profile can also be provided in the PV module definition file (PAN file). In this case the 'IAM losses' tab will display a checkbox allowing to choose the definition from the PV module file. Best regards, Bruno

The specifications of the module at STC (or any other irradiance level), includes the glass cover, so it is not necessary to add it separately. PVsyst assumes that the values from the module specifications are valid for an incidence angle of 90°. It then applies the Incidence Angle Modifirer (IAM) to account for the different incidence angles along the day and seasons.

This functionality has not been implemented yet, and unfortunately the checkboxes were not suppressed. Right now, PVsyst always supposes a partition in length in the module's definition. But you can modify this in the Module Layout, when effectively using this feature. See also the following forum post. This feature will be enabled in a coming version.

There is a parameter to define this limit. In the main window menu choose 'Preferences -> Edit hidden parameters' Look for the category 'Miscellaneous'. There you can set 'Minimum monthly ambient temperature' (the default is indeed -20 °C).

The error happens, when displaying IV-curves in rather extreme conditions at the beginning or the ending of summer days. To work around this, proceed as follows: 1. In 'Module Layout', in the Tab 'Shadings 3D' click on 'Calculate' 2. Once the calculation is finished, and before(!) moving to the tab 'IV curve', drag the time slider to somewhere around noon. 3. Switch to the tab 'IV curve'. You can change the time, but avoid the last and first time slots of the day. Note, that if you go too far with the slider, and the error happens, you will have to restart PVsyst to get again useful IV-curves. We will try to fix the bug for the next PVsyst release (V6.23)

The mnimum acceptable PV module area in PVsyst is defined as 0.1 m^2, which is apparently too large. For the next Version (V6.23) this has been reduced to 0.01 m^2. In the meantime, to work around the current size limitation, you can perform a simulation with module dimensions that are too large, as long as you do not define the 3D shadings. The results should be correct, with exception of the efficiency figures, which scale with the module dimensions. All other relevant results, like produced energy, losses, PR, etc. should not be affected. Thank you for reporting the issue.

Transforming the solar irradiance from the tilted plane (POA) back to the horizontal is a non-trivial problem, involving some modelling. If you have POA values that you want to use, the way to go is to import them through 'Databases -> Import ASCII meteo file' (check the online help and tutorial for instructions). This will do the transformation back to the horizontal plane, but be careful with some pitfalls described in the following two FAQ entries: Can I import POA measurements ? My transposed POA values don't match the imported values

At the bottom of the loss diagram you will find three values: 1. From grid: Is the energy that had to be bought from the grid to cover the specified load during times of unsufficient solar production 2. User: The part of the load that was covered by solar production 3. to grid: The energy that exceeded the user load at times of high solar production, and that was sold to the grid From these definitions you can do the following crosscheck: 1. + 2. should give the load that was specified 2. + 3. should give the Available energy at Inverter Output.

This limitation has to do with the internal representation of the dates in the program and cannot be easily changed. But it is noted, and this limitation might go away in one of the future releases. Meanwhile, the only workaround is to change the year in the data file with search/replace to a value between 1980 and 2060. I will include a clear remark on this in the online help. Thank you for reporting the issue. Bruno Wittmer

Dear Martin, the sun height, which is at the input of the shading calculations, depends only on the date and time, and of course the geographical coordinates of the site. It is expressed as an angle, which is the same at all points of your shading scene. This means, that we treat the sun beams as a perfectly parallel bundle of rays, which is a fairly accurate approximation of real conditions. So the answer to your question is, that only relative placement of the objects with respect to each other is relevant.

The discrepancy is due to a bug that was introduced in V6.13 and corrected in V6.19. The tilt for the calculation of the diffuse shadings was not correctly read from the file and lead to an error in the calculation. This error happens only for calculations with unlimited sheds. The results ov V6.21 are the correct ones. Best regards, Bruno

You need to put the '.OND' file into your Workspace in the directory 'PVsyst6_Data\ComposPV\Inverters'. Then from the main window you choose 'Databases -> Grid Inverter' The inverter will show up in the list and you can have a look at it by clicking 'Open'. Best regards, Bruno Wittmer

The deviations you observe can be due to rounding errors, since the percentages in the loss diagram are displayed with a precision of one decimal. Your reasoning is correct, the losses reported in the loss diagram should match the result summary. If, for crosschecking, you would like to repeat the whole calculation, you can export all the intermediate results of a simulation by selecting 'Output file' in the Simulation Dialog. Here you can make a choice of the variables you would like to look at and have them written into an ASCII file. In this way you should get less rounding errors. Best regards, Bruno Wittmer

Dear Martin, the horizon shadings are supposed to be at 'infinite' distance, which has two consequences: - The angle under which the sun gets shaded is always the same, irrespective of the height above ground. This is why the horizon line is defined as a series of solar height angles as function of the azimuth - As a direct consequence, for a given sun height, the shading is either completly on or off for the entire installation. This approach works well with far away hills and mountains. If you have shading obstacles that are close enough to the installation, so that the height at which the modules are mounted makes a difference, then you have to model them as a 3D objects in the 'Near shadings'. Make sure to include only objects that can actually cast shadows on your PV modules, since the near shadings consume much more CPU time during the simulation than the simplified horizon shadings. Best regards, Bruno Wittmer

In the top left corner of the System definition window, there is the field 'Global System configuration'. It is here that you select into how many groups you divide your installation (2 in your case). This will create the corresponding number of tabs for the sub-arrays. You then assign an orientation to each sub-array and do all the specific configurations for that group (modules, inverters, etc.) Note that you can also have inverters sharing two orientations, by choosing 'Mixed #1 and #2' for the orientation of a sub-array. I recommend you to give meaningful names to each sub-array (Default is Sub-array #1, Sub-array#2, etc., which is not always very talking). This will make the task of module layout easier. In complex systems with many sub-arrays and several orientations, it is helpful to look at the button 'System summary', which will give an overview of the main parameters of each sub-array. This button can also be found in the dialog of the Near shadings and system layout.

The values in your picture correspopnd to the NASA-SSE data for Santej. Meteonorm, which is the PVsyst default, gives slightly higher values for the Global horizontal irradiance and slightly less for the diffuse, which means that it has less clouds. I recommend to make a simulation with both inputs, to get an impression of the impact this difference has on the result.

The meteorological data, which is at the input of the simulation, accounts already for cloudy conditions. The solar irradiance arriving at ground, splits up into the direct (beam) component, which is only strong if there are no clouds, and the diffuse component, which is always there at daytime and usually increases in the presence of clouds. Therefore, to get a useful simulation result, you have to make sure to use reliable meteorological data for your input, that reflects the meteorological conditions at the site of your PV installation. The default meteorological data source in PVsyst is Meteonorm, which provides reasonable values for any spot on the globe. You can also choose other meteo data sources as explained in the Tutorial and Online Help. In this case make sure to validate the data quality.

Hello Raam, the format of the csv files at 'Solar Prospector' are not TMY3, so it will not work to import them the way you are trying. If you really need to work on the csv files instead of the tm2 ones, then you need to use the dialog for importing ASCII files (Databases -> Import ASCII meteo file). The format of the csv files is explained on the 'Solar Prospector' interface and you need to specify it in PVsyst accordingly. You can refer to the tutorial Part3, chapter 6 'Importing Meteo Data from an ASCII file' Best regards, Bruno

When you select 'net metering' in the project dashboard, an additional button 'User's needs' will appear (see attached picture). This button will lead you to to a dialog, where you can specify the load of the system. The dialog proposes many different ways to define the load profile, and there is also the option 'Load values read on ASCII file', which allows you to import the data from a csv or text file. See also the online help topic 'Project design -> User's needs' for a description of the available options. Best regards, Bruno Wittmer Net metering switch

The Performance Ratio PR, as it is used in PVsyst, is defined in the international standard IEC 61724. It does not include a temperature correction for the reference yield, as you are showing in your formulas. Therefore, the correct expression should read: E_Grid = Pnom * GlobInc * 1kW/m2 * PR You did not mention the Pnom for your example, but from the table you provide I calculated it to be 1.080 MW and the PVsyst values obey the above formula (up to the rounding errors). See also the following FAQ : http://forum.pvsyst.com/viewtopic.php?f=30&t=697, or the PVsyst online help 'Project Design -> Results -> Normalized Performance Index' Best regards, Bruno Wittmer