André Mermoud

There is no way in the present time for explicitly defining the tracker's position. Providing such a possibility (i.e. defining the tracker's position by an external file) is on our roadmap, but will not be realized before several months.

The simulation works exacly in this way: the individual inverter limitations are applied first. And if the grid limit imposes an additional restriction, it will be accounted as "Unused loss" in the loss diagram (provided that you have specified "Accounted as separated loss" in the grid limiting dialog). If you uncheck "Accounted as separated loss", all the losses will be accounted as inverter losses.

Yes, these are two different bugs. We will correct this for a next version, but I don't know when. NB: There is indeed no way of modifying the number of cycles within PVsyst in th present time. The only possibility is to directly edit the *.BTR file, for example in Notepad, and modify the parameters at the end of the file:

Yes indeed. providing an hourly definition of the Grid limitation is on our roadmap. However I don't know when we will be able to develop this feature.

This doesn't make much sense. The voltage mentioned here is a limit for operating conditions. The current is roughly proportional to the irradiance. The input current limit has not a "universal" definition, especially at the array level. It is not always well defined in the OND files.

As it is implicitly involved in the post of DTarin, in the present time the AC losses (Line + transformers) don't take the impedance into account; the calculation is purely resistive. Implementing the lines impedances is on our roadmap, but we don't know when we will do that.

The difference is 0.0013 %. Is it really significant ? This is a rounding effect when reading the file.

I don't know. To our knowing, the "Peak shaving" feature works quite well. Please send your whole project to support@PVsyst.com, using "Files > Export projects" in the main menu, in order that we can analyse your problem.

The Perez model calculation has not been changed. It is well-known that the Perez model has a higher gain that the Hay model. For fixed planes the difference may be of the order of 1%, depending on the tilt of course. Here you have probably a tracking system, perhaps with backtracking. This difference of 1.6% seems indeed high, but is probably reasonable. Please check that all other parameters of your simulation are quite identical.

Basically, in the present time, PVsyst works in hourly steps. Therefore this is not possible. By the way, providing 10 min output data would require to avail of 10-minutes meteo data (irradiance and temperature).

The classes are indeed of 50 kW (this is mentioned on the axis ... since the version 7.2.18! ). Now I don't have any explanation to this variability, this is a statistical variability.

You should indeed simply redefine a HV transformer rescaled according to the nominal power for each system. For your system of 1/6 of the full power, you will simply take 1/6 of all Powers specified for this transformet (nominal, losses)

This error has been very probably corrected in the latest versions, please update.

Yes of course. Any inverter or PV module may be used in building installations, without restriction. Obviously some models are more specifically suited for this use (for example modules for façades, waterproof roofs, or semi-transparent), some inverters with storage management, etc). Many of these components may be present in the PVsyst database. But sorry, there is no filter for identifying them according to their specificities.

I don't know. We don't use Helioscope. However to locate the problem, you should probably compare the results at different stages of the simulation: Meteo data inoput and Irradiance on the PV modules, shading losses, output of the PV array, output of the inverter, AC losses, etc. I don't remember any recent complaints from users about such comparisons and differences.

Remember that the "Additional data => Measured data" page is a tool for analyzing the low-light data, usually recorded according to the IEC61853 norm. This tool allows to import measured data, but it is completely independent of the "edited" PV module. After importing, you can play with the parameters for adjusting at best the model to the measured data. When exiting this tool you can ask for adjusting the parameters of the "father" PV module, in order to get the same low-light behaviour at 25°C that you have chosen. This will not necessarily result in the same Rserie, as the STC values of the "father" model are not necessarily identical to the values measured at 1000 W/m2 and 25°C. In your case the Rserie is indeed identical (0.186 ohm). However the parameters chosen for the "measured" module are not saved on the file. When you reread the module, the Rserie/Rshunt values are set to an initial value defined by PVsyst (i.e. default rel. efficiency@200W/m2 = -3%). You can observe that on the second image, the mention "RSerie optimized" appears, when it is not present on the last image.

Yes, this is a problem that we are studying. This will probably be improved in the next version 7.3.

This bug has been fixed in the version 7.2.19. The value "produced energy" is not correct, the results E_Solar + E_Grid at the bottom of the loss diagram, or on the monthly "main" results, is the correct value. The error is 0.62%. This affect the PR shown on the Main results.

As I understand, this seems to work exactly like a storage integrated in your system. The only difference is the battery efficiency, including the charger and discharging inverter losses. You can define high values for their efficiencies. I don't see what you mean by "no load time". In your case, the cost of the battery (purchase + wearing depreciation) is replaced by the rent fees.

We don't consider offering an API for PVsyst in the near future.

In the version 7.2.17 of PVsyst, we have implemented the option of forbidding the grid reinjection when self-consumption is used, without storage. This option appears in the User's load definition dialog: In the Loss diagram, this will result in a n "Unused energy" loss.

This comes indeed from optional parameters sometimes defined in the inverter's specifications: If the case "required" is not checked, this is just an advice of the manufacturer. Don't care. It doesn't make much sense to impose such limitations on the PV array, as limits are managed by the inverter during operation. If the case "required" is checked, this is a contractual requirement: if you define a system overcoming this requirement, the warranty may be dropped. In this case PVsyst forbids this configuration during sizing.

Sorry, I don't identify the apparition of this fleeting little mark. It is probably a Windows artefact that I have never noticed. But this has nothing to do with the indication that this case is checked or not, which appears as a blue-background check mark. However it is indeed not always possible to get the default value of Rshunt (depending on the other parameters, especially Rserie). And this is not really necessary, often a higher value (1000 ohm or more) is more suitable as it increases the RSMax value. See the help (little blue questionmark).

Sorry, I wrote a stupidity. I did not find the dialog for the HV line up to the grid injection, as it only appears when you choose the HV transformer in the combobox. I was really aestonished of that, I did not remember that I had programmed this as such (a long time ago).

I don't understand well what are your power stations, and what you mean by "PS1-PS2", PS2-PS3" and "PS3-SET". If these are transformers in series, PVsyst only treats two stages, i.e. a section "Inverter => MV transfo", and a section "MVTransfo => HV transfo". The wire between HV transfo and Injection is indeed not taken into account (this is a weakness of PVsyst). In this case the losses (in percentage) should indeed be added, as they concern the same power or energy flux. Now when you define 3 MV transfos as you did, this means 3 circuits "Inverter => Transfo" in parallel. In this case the losses have obviously to be added in terms of energy (kWh). And the loss in percentage will be the total loss in energy, divided by the total transferred energy. Please carefully read the Help "Project design > Array and system losses > AC ohmic loss from inverter to injection point" And also "Project design > Array and system losses > External transformer losses"