All Activity
- Today
-
rjv7888 joined the community
-
Bruno Wittmer started following Batch Params Field Name ix
-
I assume that this question is about the Backtracking parameter in the batch mode. The way it works, is that in this column you can enter the characters Y or N for each simulation, and this will activate or deactivate the backtracking mode respectively.
-
Dear Oscar First of all, in the "unlimited shed" orientation, the sensitive width is the total width of the modules aligned on your PV table. For example, if your PV module is positioned in landscape in your 3D scene, the smaller side is 1.134 meters. Since you want two rows placed one above the other in each table (still in landscape), you need to multiply the smaller length by 2: 1.134 × 2 = 2.268 meters. In my example below, I used 2 meters as the sensitive width. You can always verify in the 3D scene whether the sensitive width value is correct. But if you already know the dimensions of your PV module, its orientation (landscape or portrait), and the number of rows per table, you can calculate the sensitive width. You can also click on the "Help" button in the "Show Optimization" window — it will open a help page with a full explanation (see below). If you need more information or something isn’t clear, don’t hesitate to reach out to us. Regards,
-
BNPI conditions cannot be used as input in PVsyst. You could use the BNPI test report to re-evaluate the bifaciality factor. But per se the BNPI result will not be used in the simulation (in which irradiance and temperature conditions vary at every step). To calculate the bifaciality factor the approach would be as follows. The basic equation is Pmeas(BNPI) = P(1000+phi * 135), and solve for phi (bifaciality factor). This could be solved by trial and error using the PAN file interface to evaluate P(irradiance, 25°C), but it will involve manual steps. Once you find which irradiance yields P(BNPI), you can easily find phi.
-
Currently, if the two-sided efficiency is applied, it is shown that only the Bifaciality factor is applied under the STC condition. Now, we are receiving the test report of the double-sided module under BNPI conditions, can we apply BNPI conditions?
- Yesterday
-
Hello everyone, I am writing you in order to clarify something that I am missing right now. I first when to orientation management to try to check the optimization for my sheds with a tilt angle of 30º and 1º azimuth and 4 meters pitch. There, I thought that the Sensitive width would correspond to my panel length (one of 2.33 meters). In my case I am using in the 3D scene sheds of 2 modules in height so in total, that sensitive width would correspond to around 4.7 meters (2*2.33 plus 0.04 of inactive band). However, when I put the value, it proved that it should be wrong: So, I decided to go to the 3D shading scene and directly create my arrow of panels to try to discover what this width corresponded to. As you can see, this would be the limit angle and the GCR for such panels and such pitch: Looking at this, I thought that the heigh in the sensitive area above could be the widht introduced in the orientation , so I went back and introduced it: Looking at the Shading limit angle and the GCR it could be approximately (it is not exact) what the sensitive width stands for. However, this arises the question: is there not a way of knowing beforehand the sensitive widht? Do have I to go to the 3d shading to know this parameter and then enter it in the orientation management? Iam interested in the shading graph and the show optimization. I also though that it could be calculated with the sin30º or the cos30º with a hypotenuse of 4.7 meters (the length of the two panels in the shed). However, the closest value would be 2.35 meters (y) which also doesnt correspond to 2.29 meters... Hope I explained myself correctly. Thank you very much in advance.
-
Oscar Aviles joined the community
-
StKog joined the community
- Last week
-
Hi, is there a recommendation for a Uc value for single axis tracker (N-S) with 1 modul portrait? Thanks
-
Yes, actually the irradiance of front side + backside*bifaciality factor are put together, which gives an effective irradiance evaluation. Only after that, the PV conversion model applies. Indeed, the light reaches the same cells, be it from the front or the back. The same low-light performance is therefore taken into account for front and back (up to the bifaciality factor).
-
The temperature is generated from the monthly values saved in your site file, using the Meteonorm algorithm https://www.pvsyst.com/help/physical-models-used/synthetic-data-generation/index.html
-
Thank you for your explanation. May I ask how the Tamb is generated?
-
thanks
-
André Mermoud started following Cell Area and Quick orientation optimization (acc. to clear-sky model)
-
Quick orientation optimization (acc. to clear-sky model)
André Mermoud replied to Sydwell's topic in Meteo data
There is no automatic way of optimizing the system for summer or winter in PVsyst. You are probably thinking about the "Quick optimization" tool present in the "Orientation" definition dialog. This is just an "immediate" tool for indicating how your present orientation choice is situated with respect to the optimum for this period. This choice doesn't modify anything in your orientation parameters, and therefor nothing in your system definition. -
Good day, I have noticed that when I optimise my simulation for winter or summer, this does not affect the results and the results are the same as oprimised for annual yield. Might you advise what may be the issue. Best regards, S. Matolo
-
Engr. Munir Ur Rehman joined the community
-
Antonio Carotenuto joined the community
-
Thank you! I will give that a try.
-
Modules following terrain slope in 3D shading scene
Jéremie Bernier replied to emily.denz's topic in How-to
Hello, to better assist you, please send the export of your project, including the problematic table name, to support@pvsyst.com -
Modules following terrain slope in 3D shading scene
emily.denz replied to emily.denz's topic in How-to
Thank you for your help. For some reason the Baseline slope is not adjusting, as you can see in the screenshot - I think that is the reason why it is not working. How can i change this? -
Trevor Turnbull joined the community
-
Engr. Usman Javed joined the community
-
ADAGE RENEWABLES joined the community
-
Bryan joined the community
-
Turning on Bifacial when using 2 different module types of different size
Robin Vincent replied to Jig's topic in How-to
If you have only two types of modules in your system, you can still create two orientations. One to be used for all subarrays of the 1st type, the other for the 2nd type. These two orientations can have the same parameters, but it will allow you to setup your bifacial system with two module sizes. -
Actually I have 40 separate subarrays. 8 of them have one module type. 32 have the other. All share the same "orientation".
-
In one of our project sites, the rooftop surface is covered with gravel (dark-colored stone material). Could you please advise on the most suitable Albedo value to use for bifacial module simulation in this scenario? Kindly refer to the attached roof image for reference. Finally, please consider the effect on reflection, as it is a rough surface, not a smooth surface with one color.
-
Modules following terrain slope in 3D shading scene
Jéremie Bernier replied to emily.denz's topic in How-to
Hello, If you’d like to fill an area on a hill with PV modules, you can use the Zone Editing Tool. Once you've defined the zone using either a rectangular or polygonal area, click on Field Properties and set the desired tilt and azimuth (select Uses average), then click on Fill Zone. Here’s an example of how a filled zone appears on hilly terrain: After filling the zone, you can select and edit an individual table (like the one highlighted in the scene above). You’ll notice that the baseline slope is automatically taken into account. The Basic Parameters of the selected table will also show the actual tilt and azimuth values for that specific table: Hoping this helps you. -
This is probably due to a bad definition in the PAN file used. I have corrected / securized this problem for the version 8.0.15, to be released mid-august 2025.
-
Regularity is defined vaguely by PVsyst. If the system is approximately regular, e.g., patches of trackers or tables that are more or less evenly spaced, then this can be considered “regular” in the PVsyst sense. In that case, you can use the 2D bifacial model jointly with the 3D scene. PVsyst will check the following points: The RMSD of the pitch distribution. If the RMSD is too large, PVsyst will throw an error. You can change the threshold of the error in the advanced parameters. Whether the tables are the same height. If there are differently tall tables, PVsyst will throw an error. Whether orientations have more than 2 rows. If there is only one row of tables, PVsyst will throw an error. The average axis tilt of the trackers in each tracker orientation. If the average axis tilt is too large, PVsyst will throw an error. You can change the threshold of the error in the advanced parameters.