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).

Yes indeed, your configuration corresponds to what is named "connexion in cascade" in the help. This configuration is not implemented in PVsyst in the present time. PVsyst considers that each transformer is connected individually to the HV transformer input, or injection point. You should evaluate externally the global loss of your configuration, and define lines at the output of each transformer in order to get the same energy loss. The help https://www.pvsyst.com/help/project-design/array-and-system-losses/ohmic-losses/transfo-in-cascade.html?h=transf explains how to calculate this loss in a rather general way. Now in your simple exemple where you decide "a priori" that you want to define a loss of 1%, you can simply suppose that for each transformer, you define lines for a loss of 1%. NB: You should not define 1%/10 transfos = 0.1%, as this percentage is referred to the power of each transformer.

Yes sorry, in the Peak shaving option, the consumption of the stored energy is not supposed to arise the next day after Sunrise. This could indeed be improved, but delivering 50 MW to the grid just in the morning when the sun is shining doesn't make much sense, and is not a usual requirement.

The simulation of PVsyst uses several physical models: irradiance (diffuse from global whern necessary, transposition on tilted plane), shadings, one-diode model for PV module performance, efficiency and power limitation for inverter, different losses, etc. No regressions are involved in this process. ,

Yes, the monthly PRtemp values are calculated using the array average yearly temperature, as mentioned in the help.

For the first question: as I said previously, please check what you have specified for your discharging hours. This probablx includes 14:00. Note that the values of the hour are shown at the middle of the hour (situation between 14:00 and 15:00 os shown at 14:30. Between 13:00 and 14:00, the graph shows that you have a solar production inferior to 50 MW, so that the battery will discharge itself for complementing it to 50 MW. The situation between 12:00 and 13:00 is a little bit more complex, as during this hour, the solar production passed from overload (charging) to not sufficient (battery discharge) state. Therefore the battery begins the hour by charging, and then discharging. For the second question, I really don't understand what you mean. The max. charging and min. discharging thresholds are specified by the user in the Grid storage dialog, page "peak shaving": If these values are exceeded in your hourly values, please send us (at support@pvsyst.com) the project, using "FIles => Export projects" in the main menu.

I don't know. Please send us (support@pvsyst.com) the corresponding PAN file, as well as the datasheet of the module

In this tool, you have probably defined discharging hours which are already active during the end of the day.

This frame "Internal Model result Tool" is just a tool for showing the behaviour of your PV module in any chosed GOper and TOper conditions. You can play with these values for getting the corresponding results. But this has no influence on the PV module parameters. The reference lower temperature for the sizing of the PV array is defned in the project's settings, frame "Site dependent design parmeters", item "Lower temperature for absolute voltage limit".

Please remember the basic "function" of the PR: this represents all the losses in your system, from a reference input energy to the final yield E_Grid. The reference input energy ("nominal theoretical") is the energy you would have with the incident irradiation in the collector plane (Globinc [kWh/m2] * Array area [m2]) multiplied by the power which would be produced by your PV module when working at STC (W per kW), which is defined as the nominal (nameplate) power of your PV array. For this definition the temperature is obviously the STC temperature (25°C). Now the operating losses include the loss due to the array temperature. This is another thing which acts on the PR value. Normally you will have a higher PR in winter than in summer. The PR "corrected for temperature" is a tentative proposed by the NREL for the evaluation of the PR that you should find when you are measuring it on a little period in the year. This correction cannot be absolute, as it is based on an average TArray during a given period, which is not exactly the hourly TArray. However when calculating the PR corrected over the whole year, it should be equal to (close to) the global PR, which involves the instantaneous array temperature.

Yes this is normal: with a Vmpp lower than 880V, you have losses due to an excessive current at the MPPT input. This loss is not accounted in your simulation, because in the parameters of your inverter, you have not defined the value "Minimum Voltage for PNom", which is equivalent to a current limitation. Without this parameter PVsyst cannot "know" that the current will be limited in your real system. According to the curve PNom f(Vin) above, this parameter should be set at a value of 880 V. This is fully explained in the help https://www.pvsyst.com/help/physical-models-used/grid-inverter/inverter-pnom-as-f-voltage.html Now in this particuar case, the PNom f(Vin) curve is not quite compatible with the hypothesis of the model described in the help (i.e. the violet curve). You have: At 100%, PNom = 215 kVA. With a voltage = 880V, this means a current = 244A (full inverter) At 40%, PNom = 86 kVA. With a voltage of 500V, this means a current = 172 A. Between these points the maximum current varies on the specified curve, but is constant in the simulation (violet dotted curve in the help). I don't know the "accuracy" of the real behaviour of the PNom limit within the inverter. Perhaps you will have to slightly decrease the value of 880 V for getting your exact waited E_Grid.