André Mermoud

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.

You are probably using an old version of PVsyst. I have corrected this since a long time. Please update.

The only way is to update your PVsyst to a newer version. Or ask the provider to create the file with the option "compatibility with old versions".

I have tried your configuration and everything is OK (Global Inverter's power = 72 kW, and PNom ratio = 1.22). Now I observe on your picture that your inverter is not from the PVsyst database (grey background). Please check its parameters (namely the PNom AC value).

There are still very few bi-facial modules in the database. Only one or 2 manufacturers have proposed such modules up to now. For your first tests, you can open any usual module, and transform it as a bifacial module by defining a not null bifaciality factor (in the PV module dialog, page "Size and technology").

If you don't explain what "is not good" in the data, I can not say much. Probably the recording time is not the same as the time of PVsyst. You should apply the "Time shift" correction as advised by PVsyst (in "Databases > Meteo Tables and Graphs", page "Check Data quality"). With 1-minute data, you can also shift the dates column in your source file, in order to match the time of PVsyst (add or suppress some minute cells at the beginning of the column)

On request of SolarEdge, the reference Power for the evaluation of the maximum power is not the STC, but the maximum power attainable on the concerned site and for the concerned orientation. Therefore the maximum number of Optimizers is not an absolute, it may be different from project to project.

Yes, the presizing tool in not suited for such a calculation. It is a quick tool for "usual" stand-alone sytems, where the normal autonomy is of some few days. The error is that this specification is allowed.

The old tool concerns mismatch between individual modules. For the current, the mismatch is mainly due to the worst current module in each string. For the voltage, the differences in voltage add-up for each module, this means that if you have a given RMS distribution for all modules, the voltage difference for a full string will statistically be RMS / sqrt(n), where n is the number of modules in series. So the mismatch in voltage between strings is much lower. The new tool aims to evaluate the mismatch in voltage between strings. When dealing with string voltages, the average power loss due to the mismatch is the difference between the sum of the MPP powers of each string, and the effective resulting voltage when mixing the I/V curves. Here no effect of the "worst" string: the mismatch loss is much lower. These voltage mismatches may be due to: - RMS values of individual modules (evaluated in the previous tool), - Array temperature differences, - Wiring resistances of different string lengths. This tool tries to give ways for the evaluation of realistic wiring resistances according to the tables layout and inverters position.

The cell temperature is equivalent to the array temperature, the variable is named "TArray". During the simulation the TArray is evaluated at each hour using the Energy balance described in the help " Project design > Array and system losses > Array Thermal losses"

You can indeed create a Meteo file (*MET) of clear days for your simulations. In "Databases > Import Meteo Data", the last data source is the creation of such a file.

I don't know such problems when setting the SOC values in the Controller's parameters and saving it as a new component. Remember that you can specify the controller's thresholds either as Voltage or as SOC. However with the Voltage specification, the corresponding SOC will depend on the Battery voltage model. Please explain exactly: - with which version of PVsyst, - how you modify/save this component, and which component ? - what is not correct. NB: The SOC thresholds of the controller are used during the hourly simulation. The pre-sizing tool uses a specific value for the disconnect SOC threshold, which is specified in the Hidden parameters, page "Stand-alone System Pre-sizing", item "SOC minimum threshold".

This should represent the energy effectively removed from the PV modules (cell), i.e. the efficiency after irradiance and temperature losses. Now as I previously said, little difference don't have any impact in the expression.

This is indeed the result of this Mismatch calculation: such a low discrepancy in modules provides extremely low mismatch (it is not linear). Now what is the reality ? 0.3% RMS means 0.9Wp for a module of 300 Wp. This is a "sub-class" of the usual class powers (0..5Wp). The PV modules are indeed measured at the factory output, and "sorted" in order to get the sample with measurement results (on the paper) as narrow as possible. But what is the meaning of these measurements: - According to all Flash-test manufacturers, the accuracy of these instruments cannot be ensured with a better accuracy of +/- 3 % (for usual accuracy classes), - Probably all the modules don't degrade quite uniformly with the LID. Therefore I really doubt that the real performance (not the Flash-test result) of each module can be ensured to stay within RMS = 0.3% when installed in the system ! This is the reason why PVsyst proposes a default value of 1% (many other people/software propose 2%). Probably nobody knows the exact reality.

This problem has indeed been corrected for the next version 6.65, to be released soon.