All Activity

No electrical shading loss is showing. If these are bifacial c-Si, you'll want to include electrical effect (modeled according to strings) and then make the comparison.

Hello, I have problem creating a Tracking system in Near Shading after the 8.0.0 update. It seems that I can't connect my tables with the orientation I want. For example, I create a tracking orientation as following: In System I select the orientation I want: When I go to Near Shading, before going to Construction/Perspective the Orientation is the right one. The problem shows when I go in Zone Editing. In the Basic Parameters for my Field properties the Orientation I need is not available, even though I have "Create tracking fields" selected, so the program creates a new fixed one for me. If I go to New orientation.. an option for a tracking system is not available. What could be causing this? Can you please help? Best regards,

Hello PVSyst team, This error occurred when I was trying to simulate domes, unfortunately, I could not assign the 3D area to the subarrays I had defined in System. Then I defined two fixed tilt orientations imitating the domes. I am not sure if it's the right way to simulate. Please guide or give your input on this method to simulate the domes and what needs to be done to resolve the error attached. Thank you for your help in advance. Best, Saurabh Pansare

Hi, I performed simulations with different azimuth angles (-10 to 90 degrees, in 5-degrees steps) and surprisingly I got higher annual energy production with most of the azimuth angles that are different than zero (the project is located on the southern hemisphere). Simulation with Azimuth=0°: Simulation with Azimuth=40°: Intuitively, I would think a 0° azimuth would always give me the higher energy yield, which apparently is not so... Of course, the configuration is exactly the same, except for the azimuth. The modules are fixed, tilted 12°, and bifacial. Best regards, Rafael

Manually move the modules and objects over the image and line things up that way

No, this is not possible, even in the version 8.0.

Okay, I added some tree lines, and when I used 0,0,0, for the translation this is what came up. When I apply the automatic translation, this is what happens: Does this have something to do with the geogrpahical site location? It seems that the interactive map that pops up to download does not allow me to go to the aerial location of the project. I'm not sure if this has to do with a lat/long of the geographic location or when inserting the image. Let me know if you have any suggestions, and thank you as always @dtarin.

Hello, there is no such limitation in the fields zone creation tool. If you encounter any issue, don't hesitate to send the export of your project to support@pvsyst.com along with an explanation of what you're trying to achieve. Regards

GlobBak is not technically weather data, since it depends on the system definition. You should instead run the simulation and create an output file: https://www.pvsyst.com/help/project-design/simulation/create-a-csv-file-of-hourly-daily-values.html So is BackShd. Note that if you have defined an horizon profile, you should rather use GlobHrz, instead of GlobInc, for the frontside POA. Indeed, the horizon also affects the solarimeter.

Hello, As a contrary to the usual architect's conventions, in PVsyst we consider: In northern hemisphere, the plane azimuth is defined as the angle between south and collector plane. This angle is taken as positive toward west, i.e. goes in the antitrigonometric direction. => south azimuth = 0, north azimuth = 180°, west azimuth = 90°, east azimuth = -90°. In southern hemisphere, the plane azimuth is defined as the angle between north and collector plane. This angle is taken as negative toward east, i.e. goes in the trigonometric direction. => north azimuth = 0, south azimuth = 180°, west azimuth = 90°, east azimuth = -90°.

Is it possible that making different orientations in same string and same MPPT with new version 8.0 ? That could not possible with old versions.

Hello, please refer to this other topic:

Why, i can 't choose azimuth more than 180 degree

Add an object in the PVC file like a tree line or houses

I am trying to use PVSyst v 8.0 to import a ground image. I first imported a shading scene from PVCase, then went to file>import>download satellite image. This resulted in a location near my project, but seems to be off. Do you have any advice on how to line up the satellite image with my actual project?

Understood, thank you for the advice!

I'm trying to do PV system capacity test, and in my real measurement data I do have front and back irradiance measurements, so I am trying to match what I have from actual measurements to PVsyst model, in this case I believe I need GlobBak which has had shading applied. Just another question on how I can extract the GlobBak data when I extract the weather data from PVsyst, it seems it is not in my export at the moment. I am not able to see it under Data display and verification->Tables->Variables. Thanks,

Right now we are looking at the next minor version of PVsyst (8.1), but that could still change (before or after) of course.

Thank you Michele! When will this be implemented in PVsystCLI?

At the moment, changing the parameters programmatically can only be done via PVsyst (by using the batch mode to create and/or simulate new variants). In the future, we will extend the use of CLI so that parameters can be changed programmatically only using PVsystCLI.

Hello, Is it possible to change of LID loss, ground albedo, soiling loss, simulation year and others parameters using PVsystCLI? For example, pseudo sub-hourly simulation with change of simulation year. Thank you!

I have checked further, and the pitch seems to be effectively changed, even for the backtracking algorithm. This is despite the message saying otherwise. The message seems to stem from a check, before updating the backtracking algorithm. It is therefore not relevant. Note that this does not happen in version 8 anymore, in principle. Have you checked ?

thanx I had the same problem 🙂

Hi Michelle. Thank you for the response. Removing the Pitch column did remove the first error ("Warning: parameter Pitch did not change") but the second error ("The GCR used for the backtracking algorithm (0.675) differs from the average GCR (0.289)") remains. Below I will provide a minimum reproducible example to illustrate the error. Open _DEMO_COMMERCIAL.PRJ Click on Orientation and change to 'Tracking, horizontal axis N-S' and enable Backtracking. Click OK. Click on Near Shadings, then on Construction/Perspective. Then Create/Array of Trackers Default array of four trackers appears. Make no changes. Close Object. Click on Tools/Backtracking management. Verify that "Automatic" is checked Compute shading factor table. Click OK to exit Near Shadings. Click on Advanced Simulation, then Batch simulation. Select to vary only "Pitch E-W between trackers" Under the "Batch CSV Files" tab, select "New file" and then click OK to close the window. Open the BatchParams file, which looks like this: Modify it to schedule a batch simulation for three scenarios with varying tracker pitch: Click "Simulation" to run Inspecting the results, we see the error message is returned for cases where the tracker pitch varies from the tracker pitch in the 3D drawing in Near Shadings It seems the tracker pitch is changing each simulation but the GCR used for backtracking is not. Do you know what I'm missing?