André Mermoud

If I understand well, you have a cluster of 8 MV transfos, and a line of 3 km up to the injection point or a HV transformer. You have probably a junction box, and a common line to the injection point. Sorry, this is not yet implemented as such in PVsyst. in the present time in PVsyst you can only define a line from each transformer individulally to the injection point. Therefore for each inverter you should define a line with a length of 3 km, but a section corresponding to the power of one transformer. In the future, we will implement the opportunity of defining a junction box, and a common cable transporting the global power of all MV transformers. Please see the help https://www.pvsyst.com/help/project-design/array-and-system-losses/ohmic-losses/transfo-in-cascade.html?h=mv+transfo for further details. NB: If you are working with the "relative" AC losses (i.e. defined as percentages), and you are waiting for a global loss of, say 1% for this 3 km line, you should define a loss of 1% for the line of each transfo.

In the loss diagram, the energies are always evaluated from the previous energy. In this case, the Stored energy sharing is evaluated from the charging energy rather than the discharging. You can evaluate the available solar energy as 20'443 MWh * (1-2.3%)*(1-0.5%)*(1-0.4%*(1-2.8%)*(1-1.0%) * (1-0.6%) = 18'933 MWh. Then: 18'933 MWn * 8.5% = 1609 MWh. This is the charging energy. The direct use is 8'933 MWh * 91.5% = 17'323 MWh. Here is the detailed calculation in EXCEL: you can check that the final result is very close to the loss diagram. NB: You can get the detailed calculations of the loss diagram directly in EXCEL. In the menu of the report, you can use "Export => Loss diagram values", that you can simply paste in EXCEL.

The energy provided by the Solar system may be used: - either for charging the battery, - or (mainly when the battery is full, but this depends on the kind of system) it is directly used, either for feeding the grid or the user's needs (this also depends on the system kind). This is what is named "E Direct Use", as a complement to "ECharging (from PV)".

This graph is the distribution of the output of the system, as a function of the output power. Each bin represents the total energy produced when the system is operating at the concerned power. Now if you have overload losses, these arise always at the PNom of the inverter (or the system). Therefore they are all accumulated in the class correspond to PNom. NB: when opening this diagram in "Detailed results => Predefined graphs", you have the opportunity of adjusting the vertical scale (up/down button on the top left of the frame) for getting a "usual" distribution plot.

Please check the definition of the PV module of your first simulation. The temperature behavior is certainly false. A temperature loss of 0.7% is completely out of expected range. Except of you are at th North pole, a temperature loss is always several percents. Your second simulation shows a a reasonable temperature loss.

When editing the report, please open "Report options" in the menu. Here you have the opportunity of defining the values you want in the monthly table. The TArrWtd value is not available on the report. You can get in in the detailed results, button "Tables". Here you can generate a table of monthly values with any chosen variable (option "Custom table").

The GlobInc value is the result of the transpositiom model, and therefore independent on the mutual shadings. However with tracking systems, the tracker's position - and therefore the GlobInc - is indeed dependent on the pitch when you are using backtracking mode. Please check that in your simulations the backtracking is activated.

First question: In usual systems, (not vertical), the "Ground reflexion on the front side" is very low. Now the PR in a Vertical situation with bi-facial doesn't make much sense. Therefore we don't worry about such inaccuracies. Second question: in "normal" systems with several rows, this contribution corresponds to the reflexion of the terrain between rows. In you particular case, you have probably one only row, or a very big pitch value. This is a limit case for applying the vertical rows model. Don't focus on the PR (which is an artificial indicator meant for usual systems, with well normalized incident irradiaton), and take the real energy yield into consideration. By the way the PR for bifacial models is not well established and is subject to many discussions. If you want to use the PR for a contract, you should carefully define the way of defining it with your contractor. For the 3rd question, the IAM effect is indeed included in the "Ground reflexion on the front side" calculation, as for usual systems, this is a very sensitive correction (this reflexion occurs at very high incident angle on the front side of the collectors). Last question: you can indeed perform a similar monofacial simulation, by setting the bifaciality factor of the PV module at a null value.

Yes, sorry, there are errors in the parameters of the help. We have to correct them. Here are the correct parameters: This gives this curve:

The simulation involves many complex models. The incident irradiance is evaluated by a transposition model, including possible tracking, and losses like shadings or IAM are applied. The PV array yield is evaluated using the one-diode model. Then you have models for the inverter, the AC losses, the ageing, etc... All these models are described in the help (see especially "Physical models used").

The PAN files are meant for internal use within PVsyst. They obey to some internal coherency constraints. We don't ensure support about modifying them externally.

You define the option you want, and when clicking OK, you will be prompted for saving your PAN file with your choice.

No sorry, we don't have any additional information about the flickering effects on the inverters and the MPP tracking. Please ask the inverter manufacturer. However considering the wind turbine as a disk is obviously not the right way. PVsyst doesn't treat semi-transparent obstacles.

The user-defined state is shown according to the definition present on your PAN file (when you saved it). If it is de-activated on the PAN file, it will appear as de-activated.

You have to define this battery module in your database, and choose the required number in series and parallel. Now the best way is to choose an equivalent model existing in the database. There are plenty of batteries with 51.2V (16 cells of LFP technology in series).