Linda Thoren

This is further explained in the following help page: https://www.pvsyst.com/help/project-design/bifacial-systems/index.html#irradiance-on-the-rear-side-view-factor

Hello, Is your simulation for year 1? In that case it seems to match well with just some rounding differences of 0.01%

Hello, High annual variability indicates that weather conditions can differ significantly from year to year at this site. The purpose of running a P50-P90 analysis is to account for these uncertainties. Therefore, it is not recommended to customize the weather data variability, though you do have the option to input custom values if needed.

Hello, It is not possible to mix orientations in a string. It is possible to mix orientation in an MPPT, given that there is at least one string in each orientation. You find more information about this in the following PVsyst help: https://www.pvsyst.com/help/project-design/orientations-in-v8/mixed-orientations.html It is not possible in PVsyst to have empty MPPT inputs.

One way to evaluate such a system could be to choose the increased self consumption storage strategy and create a self consumption profile that corresponds to the energy you intend to inject to the grid. With the self consumption strategy, the batteries will never discharge to the grid, only to fulfill the users needs. Though, if you create a consumption profile with large consumption during the night you could possibly considered the energy that is "self consumed" to be what you inject to the grid. Let me know if this work around seems to be valid in your context. Kind regards

Hi Alex, The Unlimited Sheds field type is aimed for large regular systems with several rows assumed to be sufficiently long (unlimited) sheds so that we can neglect the edge effects. For only one table you must choose the field type Fixed tilted plane. Indeed it is not possible to simulate a bifacial system with a single row, though this is on our roadmap. The bifacial calculation in PVsyst is based on a 2 dimensional representation, calculating how much irradiance is falling between the tables and how much will be scattered up on the back side, thus there has to be a pitch. A possible workaround is therefor to create a 3D scene with your table and then duplicate this scene further away so that PVsyst can detect a pitch. Verify that the tables are well aligned so that indeed PVsyst detects the pitch in bifacial window. Note that the amount of tables in the 3D scene will be double what you have defined in the system and this will create a warning. You can increase this limit in the advanced parameters. In the first PVsyst welcome window, click “Settings” and “Edit advanced Parameters” and find the parameter that triggers the error message – “Shadings: absolute maximum shading/field area ratio”. This will allow you to run the simulation Kind regards

Hello, Indeed, in PVsyst version 8 you are able to define separate bifacial models, one for each fixed tilt or tracker orientation. However, dome configurations are not yet covered by this update. We will work on it for a future minor release.

Hi, What exactly are you trying to model? Are you focusing on production during peak demand hours or the price difference between on-peak and off-peak periods? In the economic evaluation, you can define different prices for on-peak and off-peak periods. You can also always generate an hourly output file with the relevant parameters and analyze the data in Excel or other external tools.

Hello Andrés, Please note that the language in this forum should be English. You can find a detailed explanation of all the possible inputs and parameters for the economic evaluation in the following YouTube tutorial: Kind regards

Hello, Indeed both GlobInc and GlobEff will be in the collector plane at the position with backtracking if backtracking activated. You can export also the phi angle to verify the position of the trackers every hour.

Hello, Indeed, if there is no production, the temperature of the modules are simply not calculated and put to 0. This has no impact of the result of the PV production since no thermal inertia is considered for the hourly simulations. For a more elegant output file we will considered changing this approach. For your evaluation you could consider the 0 as null and exclude from your average, or replace them with for instance the ambient temperature. Thank you for your input.

Hello, In general, you can define multiple MPPTs per sub-array (as long as you have a multiple between the number of strings and MPPT inputs). Indeed you have this constraint in the current version that you can not have empty MPPT inputs. To get around the constraints in PVsyst, you could modify the number of MPPTs in the OND file, though this might impact other behaviors of the inverter and you should adjust all the parameters to correspond to the use-case you are referring too. The following youtube video further explains the MPPT and Power sharing:

Hi, No it is today not possible to include that in the original simulation. If you choose to simulate both sides as front sides, that can indeed be simulated in the same variant (with the proposed work around of modifying the .PAN files) You are right, the thermal losses only consider front side irradiance, we will look into this. Kind regards

Hello Luis Zimmermann, In PVsyst, the beam and diffuse components and the rear side of a vertical bifacial PV system are calculated similarly as on the front side, by computing the integral of the visible sky. For the rear side irradiance, this is done using a 2D intersection method, same as the "unlimited shed" field type. If the layout is done in the 3D scene, the visible sky is instead in 3D. With bifacial systems, the view factor model also estimates the contribution of ground reflection to the front and rear side (not considered in mono facial simulations).

Hello, In the economic evaluation, you can include hourly tariffs to assess the financial benefits of a peak shaving strategy. You can in the peak shaving strategy specify the hours when you allow for the battery to discharge and inject to the grid and calculate the revenue based on the corresponding tariff rates. However, the system does not work in reverse—economic data cannot be used as an input to control battery storage behavior.

Hello, Indeed the peak shaving is not design for this exact purpose. With the peak shaving strategy you will only store the energy above the set grid limitation. Setting a lower grid limitation will allow to charge the batteries and then you can set the specific hours for when you want to discharge the batteries. Indeed the discharge of the batteries will also be limited to the set grid limitation threshold.

If you have less production, there will be less energy to charge the battery with, no matter the size of the battery. But it could indeed also depend on the charging and discharging power

Hello, The system is not completely the same before the battery (you have a 9.2% loss to the right compare to 2.3% to the left), thus you have less solar production to the right. Also have a look at for instance the charging and discharging power. Kind regards

See example below from the DEMO commercial project where indeed the first year simulation match the result from the aging tool. If your issue persists, please send your project as a .zip file to support@pvsyst.com Kind regards

Hi, First time you ran the simulation, did you use the aging tool in the detailed losses? in what year? When you activate the aging in the detailed losses, the first proposed value is to run the simulation for year 10, possibly the first PR correspond to year 10? Kind regards

Indeed this is a limitation of the bifacial model today. A possible workaround, is to modify the .PAN file and place two panels back to back. By creating separate modules for the front and rear—each with a bifaciality factor of 0 (and adjusted properties, e.g., lower power, no AR coating for the rear)—you could place them back-to-back in the 3D scene and simulate the system using the Module layout. This wouldn’t fully replicate real system behavior, and on clear days electrical shading losses might be underestimated due to the fact of having two panels instead of one. This in not necessary a recommendation, but could work as a test to evaluate the shadings for the backside. Otherwise, for the estimation of the electrical shading losses in general for a vertical EW system, the irradiance distribution on the rear side should be roughly as uniform as on the front. This means that, in principle, the rear mismatch factor should be set to zero, as it only accounts for additional non-uniformity on the rear. However, since PVsyst currently calculates electrical shading losses only for the front side, using the rear mismatch factor as an approximation for rear-side shading losses is reasonable. That said, determining whether 5% is an accurate value is difficult, as it depends heavily on system geometry (row height, spacing, etc.). As a first approximation, it would be best to adjust the rear mismatch factor so that its corresponding losses in the loss diagram match the electrical shading losses multiplied by the bifaciality factor.

Hello, Indeed this is not very straightforward. The irradiance on the rear side is renormalized to the 4806872 m2 of collectors after the View Factor (1111 -73.71% -81.34% * 14897331/4806872 +15.6% +0% -9.9% results in 176). This further explained in the help page below: https://www.pvsyst.com/help/project-design/bifacial-systems/bifacial-systems-results.html

Hi, at the moment PVsyst cannot simulate the backside irradiance for domes. Note that in general the bifacial gain of dome structures is negligible, unless they are installed very high above the ground. So your results are not really useable like this. The backside irradiation model is a 2D approximation that currently only works on single orientation rows. It does not take into account shading objects from the shading scene, as the rows of panels in the opposite orientation. Regarding the height above ground (that is defined in the unlimited 2D Model tab) and the albedo, normally it is possible to define this for each orientation if you save the definitions (clicking OK)

Hi, This is not on the road map at the moment. If you wish to have an unavailability in production loss, such as in soiling losses, you can indeed put the unavailability in the soling losses tool instead.

Hello, Indeed if it is a grid limitation can be applied in the Energy management window, Grid power limitation, instead of modify the inverter. If the grid limit is in apparent power, note that you here can change the limit from active power to apparent power. Kind regards