dtarin

Does PVsyst have any plans to allow the linking of smaller partitions to create a full partition? Such as when modeling with 4Hx6L tables, three of them will count as one string in length (if defined that way)?

Hello, PVsyst is unable to batch process the tilt variable when ground terrain is incorporated. It seems that what PVsyst is doing is when a tilt is selected, it adjusts the tilt of the tables in the shade scene, and in the orientations section, to the input value on the batch parameters file. However when ground terrain is included, the tables, when set to a given tilt, do not add end up at that tilt; it may be 25.1 degrees instead of 25 degrees. The error shown states "orientation", so this may include both the effective tilt and azimuth calculated in the shade scene with terrain. It would be ideal if PVsyst, in the batch simulation process, took not the value(s) entered by the user in the batch parameters file directly for the orientation input, but instead the effective orientation (tilt/azimuth) from the shade scene, which is calculated after all tables are set to a specific tilt/azimuth (given in the batch parameters file), and used that for the orientation parameter, so that the shade scene orientation and that entered in the orientations section matched. For bifacial simulations, it would be necessary to have this updated as well based on the result from the shade scene. Perhaps more simply, the "update orientation parameters" step is missing from the batch simulation procedure (see second image)

1. Yes. Yes. 2. Select tracking tilted or horiz. N-S axis option under orientation. Under system, select bifacial system above the pan file and select use unlimited trackers for 2D-model. Enter your inputs. Define system (inverters, strings, etc). Go to near shadings, construct a tracker block which matches your orientation settings (tilt if any, tracking range, backtracking/no backtracking). Ensure the tracker block matches your design in terms of module orientation, width, pitch, and representative length of 1 or more strings. Define your partition. Save, exit. Select according to module strings under near shadings. Go back to the bifacial system settings and ensure your inputs match the shade scene: pitch, width, tracking range, etc. 3. The waterfall should be calculated sequentially. In addition, the numbers are rounded (only showing one decimal place). You are not likely able to reproduce the result based on the waterfall. When calculated sequentially I get 367,533.5 (backtracking report), which is due to the rounding of losses in the waterfall.

In NA, backtracking with bifacial yields higher than non backtracking I believe in most cases I've seen (c-Si module). I did a test on a site of mine in Southern US; backtracking was 1% higher in total energy than non backtracking. Near shading loss on a 39% GCR without backtracking was ~6%. In seeing your high irradiance, I picked a different location (Chile) with similar yearly GHI, and this trend was also present for this region. 39% GCR, one module in landscape, using the 3D shade scene for calculations and not unlimited sheds. This trend would be the same for monofacial. I would suggest building out your model in the 3D shade scene and ensure your inputs are correct and the same for both models (pitch, etc).

Did you model with the unlimited sheds method in the Orientation menu? The electrical effect loss is not shown in the backtracking version's waterfall. I would double check you have modeled shadings properly for both cases. Even when electrical loss is zero, it still displays in the waterfall in v6.78. Either using the unlimited sheds method, or constructing a shade scene and using the "according to module strings" option (more accurate method). These two statements are in agreement and say the same thing. Backtracking reduces POA and lowers shading losses. The reports confirm this. "Total irradiance received" = global incident in collector plane. Make sure you have properly modeled these with regards to shading. If you have a very low GCR, it is possible your shading losses without backtracking are such that the POA gain is higher than the shading loss incurred. Location may be a factor, you have very high irradiance; might be something unique to your location.

I would think so. It 'd be ideal if the option in the bifacial option syncd with what is selected in orientation parameters/shade scene.

My guess is that one is for the shading loss and transposition calculations, etc, and the one located in the bifacial section is for the bifacial calculation. Checking all, one, or none in that case would give you a different result in each of the three scenarios.

Hello, It would be helpful if PVsyst were to permit the simulation of a non-uniform pitch in the shade scene with a bifacial system. Perhaps it could compute an average pitch, or the user could enter a single pitch for the bi-facial calculation.

Interested in hearing feedback on this.

How did you define your partitions? It's possible that the pole shading is not significant, and with backtracking, results in approx. 0%. In the winter time, module loss according to strings is probably low, and when weighted with the rest of the year, does not result in noticeable losses. When I do a test, I get .001% elec effect losses.

I also have this issue.

Hello, Presently when entering module X and Y spacing, PVsyst takes N modules (X or Y) times the spacing and adds it to either width or length. Should this be N-1 modules times the spacing, and then added? This would present a method which allows PVsyst to match construction design drawings.

Hello, It would be useful to allow the electrical effect parameter to go above 100%. The purpose would be to tune models where there is disagreement with measured data as it is concerned with shading. In cases where the model under predicts, it would serve to add additional shading related losses appropriately, by keeping the additional losses as a function of site conditions, time of day/year, etc.

It is possible to download SolarAnywhere data as a .csv file or as a 'SolarAnywhere' file format, in which the latter would use the SolarAnywhere menu selection in PVsyst.

Hello, Are there any plans to have zones work with tracker systems? Or some other method to modify tracker designs more easily? Presently it is a very manual process and cumbersome process to work with trackers. It would be useful if a selection tool allowed an array block to be split as selected. For example, a rectangle is drawn encompassing a number of tracker rows, and creates new blocks which remain in place. From these three separate tracker blocks, 9 are created, which allows the quick removal if the middle area in the area needs to be removed during a later design stage (image for reference).

Hello, It would be useful if when a table or shed is copied/pasted in a shade scene, it takes the name of the table copied and adds a numerical value which increments by 1 so that each copied table/shed/object has a unique name. Copying/pasting sheds/tables saves time, but when there is an error associated with one, presently it will refer to the name of the table; if copied/pasted, it will have the same name unless a unique name is entered each time, which is time consuming when there are a number of elements copied/pasted. Thanks.

Hello, It would be useful to be able to select multiple 3D polygons and edit the height for all simultaneously. Presently, only color can be modified when selecting multiple polygons. Thank you.

If you imported the SolarAnywhere file as a .csv, you will use the NREL TMY3 format for import, no modifications needed. Edit: I just tried importing a .csv solaranywhere file using the solaranywhere format and I also received that error, so I would suspect that is also what you are doing.

Have you figured this out?

Related to this suggestion and modifying tables, it would be nice to have included the frame size in this menu (picture shown for tracker sheds)

This can be overridden in the OND file. Under Contractual specifications, uncheck the box next to "Maximum PV Current". This has no impact on the simulation results.

There was a previous forum post which said +/- 1 degree would still simulate, but i set my trackers to +0.5/-0.5, and I still received the error.

Hello, Is it possible to model a horizontal N-S tracker system in a single shade scene with different tilts? It seems not. If it is indeed not possible, is it something that could be added in the future? Thank you.

Will we be able to import ground data for terrain and have it selected as a bifacial ground object?

Change the setting in your hidden parameters under Detailed Simulation Verification Conditions