All Activity

With the Peak shaving strategy, you will indeed put any excess production into the battery with respect to the charger max power and battery state of charge. In these conditions, you can charge your battery up to 20MW, but only if the total AC power is 50+20MW. Your system will always output less than 70MW (max clear sky production being estimated to 68.23MW), but will also charge for more than 2 hours a day, so your daily charging energy will be somewhere between 0 and 40MWh/day. The actual energy will depend on the weather and battery state of charge at the beginning of the day, so you cannot predict the charging/discharging energy based on the max charging power.

Hi, I am trying to simulate a 75MWp/50MWac PV + 20MW/40MWh BESS system with grid limitation at 50MW in which the excess is used to charge the BESS. However, the requirement is to ensure that the BESS is able to fully charge and discharge 20MW for 2hours daily. Theoretically this should amount to an average of 1.2GWh per month or 14.4GWh per year. However, based on the results obtained, the EBatDis is only at 4.3GWh per annum. Storage strategy is set to Peak Shaving with the following parameters Please advise if there is any settings changes to be made to achieve desired outcome.

Hello, Thank you for highlighting this.

Hi, Several of the reference links on the help page regarding the First Solar Spectral Correction appear to be broken or point to retired URLs. Page URL: https://www.pvsyst.com/help/physical-models-used/pv-module-standard-one-diode-model/firstsolar-spectral-correction.html Updating these links would be helpful for users looking to verify the underlying physics and validation of the spectral model. Thanks.

Sorry no news yet, we are looking at update 8.2 at the moment... but that could change still.

Dear all, I am coming back to this old topic to see if there is news on this subject of 3D scene + dome + bifacial modules

Hello, The losses due to the wind stow position of the trackers do not directly appear in the loss diagram. The only way to evaluate these losses would be to run a simulation without wind stow and evaluate the difference between the simulation. If you are using sub-hourly data and the sub-hourly clipping correction model, you find the additional clipping correction printed in the loss diagram. Im not sure what you mean by terrain loss? With the 3D scene, you can evaluate the mutual shadings that might appear due to the terrain, as well as shadings actually caused by the terrain, these will be shading losses. Shadings from shading objects or the terrain will be grouped together. To evaluate them separately, you would need to run several simulations with and without the different shading objects. You can also import a horizon profile to evaluate far shadings.

How to evaluate the Wind stow loss, Subhourly loss and Terrain loss for Utility scale solar power plant, here we are using single axis tracking system and central inverter.

Hello, No it is unfortunately not possible to use the plane of the array measurements directly. You can import the horizontal values directly and calculate the POA from the horizontal, rather then doing a reverse transposition from the POA and transpose it back to a POA.

Hello, thank you for your response. Is it possible to add these variables manually? If precise measurements of GPOA, DHI, DNI, and GHI are available, is there a way to use those measurements directly in the calculations in order to avoid the uncertainty associated with the models? Thank you.

ReflBck = (GlobGnd - ReflLss) * GroundArea / ModuleArea - BkVFLss or ReflBck = (GlobGnd - ReflLss) / GCR - BkVFLss

Why not adjust the bifacial albedo to 0.7? If this reflector is not flat on the ground, maybe Sunsolve can simulate it.

Hello, With a grid connected system with self-consumption, you can un-tick the option "Allow solar injection into the grid"

WHAT DO I SET IN THE PROGRAM TO HAVE A PV WITH ZERO INJECTION INTO THE GRID?

Hello. Unfortunately, this approach has a fundamental limitation: PVsyst treats the ground surface as a diffuse reflector, meaning it only models albedo (reflectivity intensity) but not the directionality of the reflection. A real physical reflector tilted toward the panel's rear face would redirect light in a specific direction, which cannot be accurately replicated by simply raising ground points. Therefore, this workaround would not faithfully simulate your intended reflector behavior.

Hi, thanks for your replay You mean BkVFLss * GCR = BkVFLss_refers_to_ground? I checked these variables relationship: GlobBak = ReflBck + DifSBak - BackShd （assume BeamBak = 0） But what is relationship among ReflBck, BkVFLss_refers_to_ground, ReflLss, GlobGnd?

Hello. There is the posssibility to raise specific points in the 3d construction on the ground to immitate slopes. Maybe we could use this feature to create a sloped surface (immitating a reflector) in order to see if its possible to increase bifacial efficacy. Is that possible? I am currently working on my thesis to compare specific performance improvement methods for photovoltaic systems, and one of them is to add a special reflector with an albedo of 0.7 behind a PV table. This reflector is impossible to be added in PV syst and therefore I am trying to immitate it.

Hello, The P50-P90 statistical estimations are based on yearly values and thus it is not possible to generate monthly values through PVsyst. You can read more about the P50-P90 evaluation in the following help page: https://www.pvsyst.com/help/project-design/p50-p90-evaluations.html?

Hi, The reason is that GlobGnd, DiffGnd and ReflLss are variables that refer to the m^2 of ground area. Whereas, BkVFLss refers to the m^2 of PV modules. If you were to mutiply by the respective surfaces (ground surface > module surface), the energy hierarchy would make sense.

This is what GlobGnd and GkVFLss described in PVsyst help GlobGnd Global incident on ground, below the system. ReflLss Ground reflection loss (albedo) BkVFLss Loss due to the view Factor for rear side So I think GlobGnd is source energy for other parameters such as ReflLss and DiffGnd etc. That means value of GlobGnd should be the largest during these parameters. But I processd some simulation and looked into details of results. I found that BkVFLss always larger than GlobGnd. Does anyone know why about this? GlobGnd DiffGnd ReflLss BkVFLss kWh/m² kWh/m² kWh/m² kWh/m² January 26.1 9.94 13.06 18.8 February 41.5 13.76 20.73 35.4 March 70.9 23.17 35.45 67.1 April 98.7 27.04 49.34 96 May 125 28.2 62.51 121.1 June 124 29.7 62 119 July 122.1 32.43 61.07 117.3 August 103.1 31.35 51.56 99.9 September 75.3 24.16 37.64 72.3 October 52.8 18.7 26.41 47.2 November 30.3 12.88 15.13 23.6 December 20 10.03 10 14.4 Year 889.8 261.35 444.88 832.2 albedo=0.5 GlobGnd=889.8 BkVFLss=832.2 GlobGnd DiffGnd ReflLss BkVFLss kWh/m² kWh/m² kWh/m² kWh/m² January 26.1 9.94 5.22 30 February 41.5 13.76 8.29 56.7 March 70.9 23.17 14.18 107.4 April 98.7 27.04 19.74 153.6 May 125 28.2 25 193.8 June 124 29.7 24.8 190.4 July 122.1 32.43 24.43 187.7 August 103.1 31.35 20.62 159.9 September 75.3 24.16 15.06 115.7 October 52.8 18.7 10.56 75.5 November 30.3 12.88 6.05 37.7 December 20 10.03 4 23 Year 889.8 261.35 177.95 1331.5 albedo=0.8 BkVFLss=1331.5

Hi everywone. Please tell me if it is possible on main rezults page to get yearly results -month by month with P75 figures. As default it shows P50

Hi, I have the following limitations from the grid: Import: capacity: 150 kVA, power factor: 0.95 lag to unity Export: capacity 15,000 kVA, power factor: 0.98 lead How should I introduce this in PVSyst? Should be 15 MVA and PF 0.98 lead or 15MVA and PF 0.95 lag? Thanks.

If bifacial is disabled, the variables will not be available, same for the horizon loss.

Hello Vatsaa, Thanks for your post. It could be a network problem, also could you check that your machine time's is set automatically ? Finally you can send us some logs at support@pvsyst.com . Regards, Laurent

Hi We are working on a project that needs certain parameters in the 8760 (image attached) GlobBak (Global irradiance on the rear side) and FHrzGl (Horizon shading factor on global) does not show up in the 8760-csv file. Is it due to the bifacial model being disabled as projects are canopies, and if there are no far shading losses for the project? FHrzGl only does not come up for the sites where far shading losses are zero. I just wanted to confirm before responding to the client