Search the Community

Hello, When I import a scene from PVcase, in several occasions the tables take two different orientations automatically, either modules in portrait (3 rows x 24 modules) or modules in landscape (24 rows x 3 modules). This was not a major issue in PVcase 7 as in the orientation manager you could override this. However, in the new PVsyst 8, with and EW system I can not simulate the bifacial option as the widths of the tables are not the same (an error pops up). If I change manually in the list of objects the configuration of these "wrong" tables, they move all over the scene. How can I fix the error in importing/reading correctly the tables? This would also reduce the threshold of the setting in max. spread of azimut for the same orientation. Note: this is not an issue of this particular project as it has happened before in multiple projects. Many thanks!

PVcase imported trackers do not have pitch defined when going in the modify object. Does it impact backtracking? I have heard from a few industry people that it does not do the backtracking as it does not have the pitch defined (or not an array of the trackers) and all the trackers are ungrouped and are not an array of trackers Also if I ungroup an array of trackers which was created in PVsyst near shading, does this affect the backtracking? See the below snip for reference Pvcase export An array of trackers was created in Pvsyst and then ungrouped

When PVcase exported PVC file imported into PVsyst, the tracker has more number of modules than it should be (87 modules per tracker instead of 84 modules ). I know this is due to the tracker motor gap and foundation gap for terrain following trackers (Multiple bays of 7 and 8 modules with foundation gap). I tried to divide all the gaps into module spacing to achieve the tracker length and changed the number of modules per tracker to actual numbers. See spreadsheet screen shot. In the process, I modified the rectangle’s length to equal the number of modules per string times the module width. However, this adjustment reverts to the original incorrect lengths when applied to trackers with different string configurations (2-string or single-string), showing 87 modules for a 3-string tracker instead of the correct 84. As a workaround, I’ve manually selected all similar trackers and altered the module numbers using the CTRL+G command. Question is- 1. Is this the correct method? If not, do we have other methods for simulations of terrain-following trackers with multiple bays? 2. Does this affect the thermal losses as modules have larger spacing compared to actual spacing (1 inch for reference)

Imported ground image is coming in the report even after decreasing the opacity to zero in near shading. It only does not show in the report for the first time. When opened next time report has image included.

Hello, Can we incorporate parameters such as motor gap and piles gap in the near shading when creating the array of trackers? This way, the length of the trackers generated in the shading scene will align with the length of the trackers in my layout, accounting for these gaps.

Dear all, Thank you for reading this post and I would really appreciate it if any advice could be given. I was always told that PVsyst has the ability to perform large-scale simulations in terrine areas. However, when I inputted the geographic model (made in blender or downloaded google map) into Pvsyst and clicked "fill zone", there is always penetration either between module-module or module-object. Is there any way that I could delete all overlapping objects with a single click or prevent overlapping objects to be created? Another question, I have been searching on the internet about this issue for quite a while now, and that I realized not one input the whole terrine into near shading. Is loading the horizon data enough? meaning this approach unnessery? Best regrads, Ivan Leung

Hello everyone, I've been recently introduced to the concept of backtracking. Based on what I understood, the trackers are tilted in reverse to solar tracking to avoid mutual shadings between PV rows when the solar elevation is low. In that case, I would expect that the near shadings losses would be 0 (assuming that there aren't any other surrounding obstacles in the scene such as trees). I simulated a project with bifacial PV modules in a N/S horizontal single axis tracker configuration. The elevation of each tracker row does slightly differ as indicated by the topography. However, currently, we cannot simulate such a scenario, thus we assume that all trackers are of the same elevation, orientation, and size. Considering this brief explanation, what could be the issue causing the near shadings looses to be non-zero when using backtracking? If interested, I can share additional details, Any feedback is welcome, Regards

In the Near Shading Tab, when computing the shading factor table i notice that when going from higher Pitch E-W to a lower one induces some shading at low heighta even with backtracking enabled. But then i go back into the construction perspective again and i close it out without changing any of the fields and recomputed the shading factor table, the shading in the low heights is not there anymore. Is this a glitch on PVsyst? If it is, It would be greatly appreciated if this can be taken, as i would have to run shading factor table twice every time i run simulation going from higher pitch to a lower pitch. Than k you,