dtarin

Under field type select horizontal N-S tracker, not the one you have selected.

Correct, they are illustrative only for the chart, and serve no function in calculation.

There is no single right answer. Consider April, snow loss not very substantial, the average is 0.12%, which means half the time it will be less and you would consider that to mean there is not a "cleaning event" taking place. The preceding month is 0.76%, which is also low. It would be more helpful to look at the rainfall and snowfall quantities in inches instead of the soiling percentages to get an idea of how much precipitation (soling/liquid) it is receiving on average. And then keep in mind these are averages. Do you want to be conservative or aggressive? You can consider a number of ways to come up with a combined profile. I dont have all of the data, but just based off this might consider adding a baseline soiling rate to Jan, Feb, Mar, and Dec snow loss %s, and take the soiling loss %s the remainder months.

2727/96 = 28.4 mod in series. Your design specs are off. What is the correct minimum site temperature? You're carrying the PVsyst default of -10degC. Separately, it is a difference of one module, or .036%, not very significant. Depending on the site temperature and the correct string size for this location based on the module selected, you may exceed the maximum input voltage of the inverter by increasing the string size, but to the previous point, the impact is not very significant in that regard either.

.

It depends on the type and size of plant. A rooftop installation will probably have higher degradation than a large utility scale plant that has on-site operators and regular O&M support. In the absence of operational data, use the module datasheet for the Average Degradation Factor. If you want to consider system degradation, increase this figure above the module warranty value. There are some studies out there on I/V mismatch but published research is limited/lacking. If you don't have any guidance there, focus on aligning the avg. degradation factor according to expectations.

Model these as separate variants when using bifacial modules, combine post-pvsyst.

It could be something with your file type and delimiter settings? Ensure that hasnt changed. Aside from that possibility, your measurements are not correct. GHI should not be 4,000 W/m^2. Temperature, albedo, and wind speed look okay, but the irradiance variables are not (GHI, DHI, DNI). You can try using the PVsyst standard template if reusing vaisala doesnt work, but I would suggest import using custom meteo. You will define the details and each column and variable that is being imported. More information can be found in the help and on the forums.

Actually disregard the first comment, I see you are using the same table sizes for both. Check how you defined the partition area in each variant.

I do not typically disable interpenetration for the reason Michele noted, and likely causing your increased shading loss. I would either increase the table spacing from within pvcase and reimport, if the tables are not numerous and it is a fairly large site, i'd just delete them, or manually adjust. Rather than going through the check one-by-one, try flying around the shade scene and identifying by eye. Since it is a fixed tilt system, you can also look in the areas where terrain is complex and causing the interpenetrations to reduce the one-by-one check time.

The reason for the difference in electrical loss is because the string lengths are longer for the c-Si modules compared to the FS. After modifying the JKM partition as Michele noted, the elec. losses will come also come down for that module. I would evaluate how much shading is due to the trees compared to row-row to get an idea of whether or not you should include any electrical loss for the FS modules. Run a model with and without trees and compare the near-shading loss only (turn off electrical effect). Also run the shading animation in the shade scene throughout different times of the year to understand the shading patterns on the modules due to trees. If there is a lot of E-W shading from trees and there is a significant contribution, then including an electrical effect makes sense, and as michele noted, it should be low. Also, your jinko module should have an LID loss.

My only comment to PVsyst is that when PVGIS is used, the comment which displays the coordinates incorrectly shows the minutes ' and seconds " notations. The coordinates should read (degrees, minutes, seconds), but it is displays as such: 40°5"17', Long=-77°39"53', which shows degrees, seconds, minutes. Whether this is from PVGIS or PVsyst, I do not know.

Meteonorm and PVGIS both use SRTM (depending on the coordinates); Meteonorm with 3 x 3 degree tiles, PVGIS with 2.5 x 2.5. PVGIS calculates to the first decimal while Meteonorm rounds to whole numbers. PVGIS uses 48 points (excluding 0 degree), 7.5 degree increments, whereas Meteonorm uses 1 degree increments. This causes the difference in smoothness. Repeated values are excluded in PVsyst. If you evaluate a complex site, you will find there is a significant difference in the number of horizon data points between the two. For example, one project site evaluated shows 29 points for PVGIS and 56 for Meteonorm. I would conclude that the differences lie with PVGIS and Meteonorm and the methods by which each is performing the calculations. PVsyst is importing the correct values one would retrieve directly from each source.

Energy production is based off the OND file, so your inverter will output at Pmax according to Tamb and there should not be any concern for operations in cooler climates. You can output the 8760 and verify this. As for reporting, I am not aware of any way to display Pmax over Pnom in the report. You can add under report options some notes and alternate system sizes for clarification, and also edit the cover page to include details there.

Exporting the waterfall to excel is one way but misses some inputs.

You can open multiple instances of pvsyst. It will tell you another instance is open, just click to get past and you can work on any number of projects at same time.

You need to trouble shoot more. There is a source for such a large discrepancy.

Detailed design should be done outside of PVsyst. If you need something high-level or indicative, PVsyst can work, but it is better to use a software intended for PV design.

Rotate azimuth 180 degrees.

For fixed-tilt systems, the tilt and azimuth are adjusted as you have indicated. For tracker systems, tilt does not adjust.

Without looking into it, I would suggest to open a component that is in the database, rename and save as a new file. It might show up then.

For 1P trackers, you generally do not see tables with less than 1-string. Plants are dominated by 3-string trackers, then 2-string and 1-string are used to fill in gaps. It is not cost effective to install the smaller tracker tables over larger trackers, and we certainly dont see 1P trackers with less than 1-string. For 2P trackers, you can have shorter table lengths since you can string on two rows, so in this case, you can have a table row 15 modules in length and string across both top and bottom. In your case with 29, you would have 1 dummy panel.

The inclusion of motor gaps in the PVsyst table length is unavoidable at the moment. However, this doesnt materially affect your simulation. It is typical to have different module quantities in the shade scene compared to your system definition. This will not affect power output, as the system definition is used for production. The shading scene will only be used for transposition and shading losses. I would also suggest to change the default module spacing parameters in advanced settings to 0.00, and reimport the PVC scene. The spacing defined in the PVC file should then pass through to the tables in PVsyst.

This will adjust the elevation of the trackers, but not the tilt. To adjust the tracker tilt to the terrain, you will need to create a zone of trackers within PVsyst, and draw the zone over the terrain. When they are generated, they will have their tilt adjusted (as long as you select the option). The other option is to use autocad or some other software to place the trackers on terrain with tilt adjusted.

It would be useful to see some additional features for the uncertainty tool and I would like to suggest the following. Allow more user-defined fields for which p-factors to include. There is P50 default, with two additional entries for the user to define. It is common to include P50, P75, P90, P95, and P99 in financial analyses and reporting to Independent Engineers. Therefore, the request is to increase the number of user-defined p-factors available, while not forcing the user to use all of them (a toggle button to activate/deactivate). Allow the units to be changed from GWh to kWh or MWh. Allow this data to be exported (to image or excel), similar to how we can export other data such as the shading table or monthly meteo table. Allow the user to define whether the results are expressed in energy or in terms of percentages, both under Annual production probability, and on the chart. It is common in industry to post-process for additional considerations outside of PVsyst, so the energy values shown are meaningless/misleading, but the uncertainty tool can still be useful for reporting, especially since the uncertainty calculations themselves are independent. If we are able to export or screenshot the results displaying percentages, it would find more utility. i.e., P50 - 100%, P90 - 92.4%, P99 - 86.4%, etc.