André Mermoud

SolarGIS provides its data in so much different formats. We cannot automatize the import of all of them. Therefore you have to use the general tool "Databases > Import ASCII meteo files", and here press F1 for the procedure.

The clear day model in PVsyst is based on the air mass, and implies the the Linke coefficient, which is set by default to 3.5. It uses the model of Kastens. You can create a Meteo file (*.MET) of clear days for any location in "Databases > Import meteo Files", last choice in the meteo sources.

With the tool "Advanced simulation > button Output file", you can create a CSV file of hourly values. In this tool you can choose any variable among the >50 variables involved in the simulation. Obviously including the system output E_Grid.

The bifacial model for tracking systems is in preparation. It will not be available with the next version 6.68, but probably with the next one.

In the version 6.67, the IAM specified by the user is not correctly read on the custom pan files. During the simulation it always reverts to the Ashsrae model. This is a bug just in V 6.67, which will be corrected in the next version.

You are quite right. PVsyst uses indeed the expression you have calculated, with a RshRef as you propose. I have to change this in the help.

This is in preparation for a next version.

With the tool "Detailed simulation > Output Files", you can choose any variables among the >50 variables involved in the simulation (including of course the system output E_Grid) for hourly values ourput. In this tool, press F1 for the procedure.

Yes, the Site file (*.SIT) and the meteo file (*.MET) are associated to the project when opening the project. Now if you have performed a simulation with a given site, the variant file (*.VCi) will store the values of this site as Input parameters of the already performed simulation.

This is just the definition of the IAM: "Incidence angle Modifier": it is the deviation of the reflexion loss whith the incidence angle, with respect to the normal. The curve of First Solar represents the total irradiance reflexion losses. But in the usual definition of the IAM, the loss under normal incidence is fully included in the STC measurement / definition.

Yes, sorry. There are indeed problems with IAM. In the version 6.66, the IAM was not read in the internal database. This was the main motivation for creating a new version 6.67, where this is corrected. However in the version 6.67, the IAM is now not well read in the *.PAN files of your personal database ! Therefore if you want to perform simulations with your own PAN files with customized IAM, you have to revert to the version 6.66. You can download the version 6.66 from our site www.PVsyst,com, and install it in parallel with your version 6.67. Both versions may run independently.

The simulation is suited for using pyranometer measurements. Reference cells may be used for the evaluation of the stability of the PR, but suffer of IAM and spectral discrepancies. You also have to check the ageing of the reference cell (like the Pyranometers, which should be recalibrated form time to time).

There is no rule. We cannot give an advice about the better data source. And this is evolving along the time. Now I don't see any reason why Meteo stations of higher class would give higher results. Please have a look on the Help of PVsyst "Meteo Database > Import meteo data", which lists and analyzes all the sources available in PVsyst.

Yes, the google map service has been changed by Google. Please see our FAQ When defining a site my "Interactive map" doesn't work.

In the importing format protocol, page "meteo variables", you have a choice: - Irradiance given in Power [W/m2] - Irradiance given in Energy [Wh/m2] The average is used when defining the irradiances in Power.

This information is useful for the Module Layout part (calculation of elecrtrical losses). In the present time the Twin Half cells modules are treated as the "In length" modules. This information in the PAN files is here in prevision of the implementation of the Twin half-cell modules in the Module layout calculation.

Sorry, things are not so simple ... On the ground you have 821 kWh/m2 falling on 5742 m2 Reflexion (albedo) : loss -70.0% => remains 246.3 kWh/m2 on 5742 m2, i.e 1'414 MWh total View factor from rear side: loss -81.7% of the energy, i.e. 259 MWh total Now, the modules area = 2909 m2 => GCR = 2909/5742 = 0.507, 1/GCR = 1.973) => irradiance per m2 of collectors = energy back collectors / area = 259 MWh/2909 m2 = 89.0 kWh/m2 Therefore: after applying the View factor loss in %, the irradiance has to be multiplied by 1 / GCR ! Add sky diffuse on the rear side: + 23.8% => 110.1 kWh/m2 Add Beam effective on the rear side: +2.5% => 112.8 kWh/m2 Sub Shading loss on rear side: -5% => remains 107.2 kWh/m2 on the rear side. This is the value on the loss diagram. Now the mentioned percentage value is not the accumulation of all these losses, but the fraction of rear irradiance with respect to GlobEff, i.e. the bifacial relative gain 107 kWh/m2 / 1968 kWh/m2 = 5.44 % ! Loss diagram of this simulation

You are speaking about SolarEdge technology. Up to version 6.64, the treatment of SolarEdge systems was based on directives of SolarEdge edicted in 2010. SolarEdge had not updated these constraints during several years. From version 6.64, we have completely rewritten the treatment of the SolarEdge architecture. The rules specified by SolarEdge are extremely complex. They are different for each association (Optimizer - Inverters), and for US or rest of the world devices. They are not applicable to old devices, which still have some constraints of the old treatment. It appeared that the previous treatment could not meet the new requirements, and may lead to unaccuracies in the simulation, due to insufficience in the parameters description. We had to completely restructure this behavior. Now there may still be some youth problems, like the one you mention during the sizing process. We try to correct them. NB: mixing orientations in a same string is indeed allowed with the SolarEdge technology. But in accordance with SolarEdge, we have given up developing this at the moment, as this leads to very big complication in the structure of PVsyst.

In the present time, the Stand-alone option of PVsyst works with an "energy bus" in DC, directly connected to the battery. And the user's needs are specified in terms of energy, whatever the way it is used . PVsyst doesn't involve an inverter for Standalone yet (this is in preparation). Now big Stand-alone systems architectures (like mini-grids for a village) are organized around an AC power line distribution, which is very close to a normal grid. In these situations, they may involve: - standard Grid inverters for the connexion of the PV array to the mini-grid (with some precautions concerning the grid management), - specific bi-directional rectifiers/inverters for the charge/discharge of the batteries. - other sources like diesel gensets, wind turbines, etc, connected to the AC bus. - a sophisticated grid control system for the stability of the AC-bus distribution behavior. This is not yet implemented in PVsyst. Benefits of PVsyst I admit that this seems indeed rather limited in terms of system management. However we can consider that the main objective of the PVsyst simulation will be the sizing (and performance analysis) of the whole system, i.e. the battery capacity and the necessary PV array, as a function of the user's needs. The simulation also evaluates the real battery use (charging/discharging energy) for the evaluation of its lifetime. This "equilibrium" of the whole system and its evolution along the year is not much dependent on the system devices involved in the reality.

This is indeed since we have passed to the Delphi10 development platform. It seems that these buttons (which were updated by Windows in your own language up to now) doesn't work anymore. We are inverstigating this.

This has been corrected for the version 6.67. When defining your "system" configuration, please avoid defining several sub-arrays from the let-top corner control. After having defined your first sub-array, you can create a second one (copy of the first one) by right-clicking on the sub-array headre labels.

PVsyst ensures a compatibility with old files. But the inverse is not true. In particular the file format has been completely renewed between version 6.39 and version 6.40.

When I talked about the data provided by Meteonorm, I meant the Meteonorm DLL implemented in PVsyst. Yes of course the Meteonorm program provides much more information than the basic meteo data available as standard in PVsyst or other PV simulation programs.

The horizon line definition is independent on the tilt of your array, it is indeed completely independent on your system. It will be applied to the Incident global irradiance. For the measurement, you should place your SunEye horizontally.

Meteonorm provides average data over more than 10 years. Therefore the result of simulations will be P50. Now defining P90 results will use the same input meteo data set (it is an interpreataion of the same simulation). You have to specify the annual variability from an external source (not provided by Meteonorm). Please carefully read the help "Project design > P50 - P90 evaluations" NB: Very few meteo data providers propose TMY data corresponding to P90. I don't know how they construct such data.