Michele Oliosi

Hi this is still not possible. It is still as @dtarin commented.

Hi, It's definitely possible. Currently the prerequisites for the EPI test are not very strict. It is about comparing total expected energies with measured ones, filtering for various contexts, with an hourly aggregation of measurements. PVsyst will generate a time series of results with various intermediate variables, that can help with filtering (e.g. for constrained periods). This time series can easily be compared with the measured one. For capacity testing (PPI), depending on the version of the standard -2, ed. 1 or 2, it is more or less easy to do. Ed. 1 should be straightforward. Ed. 2 has minute simulation as a prerequisite. Currently, PVsystCLI or PVsyst + batch can help implement a batch of 60 simulations (one for each minute in the hour) to mimic a minute-resolution simulation. This is a bit cumbersome, though. Luckily, we are working on PVsyst 8.1 which will simulate in minutes as well. The version is well underway (and the minute simulation is confirmed to work). This will make the ed. 2 capacity test straightforward as well.

You can find more information here: https://www.pvsyst.com/help/physical-models-used/pv-module-standard-one-diode-model/pvmodule-structure/bi-facial-modules.html

When using the optimization tool with a 3D scene, PVsyst will change the nominal tilt of each individual table in the 3D scene without changing the base slopes. If there are nominal tilt differences these will be lost. If there are base slope differences, these are kept, which may result in an effective average tilt different than the value you chose in the optimization tool.

Hi ! Currently that is difficult to do for each table. For zones, a workaround can be found. The idea is to use the "partial shadings caclulation group" concept (https://www.pvsyst.com/help/project-design/shadings/partial-shadings-and-calculations.html). You can put a zone in the group. Then run the simulation, and the shading loss factor will be computed on that group + any additional shading objects (not the other tables though unfortunately). For zones the approximation should be good. This can be done through the interface, and as long as there are not too many groups should be feasible by hand. I have been experimenting with a script and PVsystCLI to try to define the groups by modifying the variant file and running the simulation programmatically. While this is possible, it is rather convoluted. The caveat of the other tables not casting shadows remains though. I need to experiment a bit more to get a result table by table.

Right, this setting is not very realistic anyway, it creates very long trackers if I recall correctly.

Good to know it works ! Actually I was not sure if [X,X] worked, I seemed to remember that at some point in the past the trick did not work unless there was a difference between min and max.

Hi, this feature is in our roadmap, but not before a few patches after the release of 8.1.0 With our internal beta of 8.1.0 we could already mimic this by running a simulation, then using that to determine a grid limitation time series that truncates the inverter power with ramps, and then resimulating with this new grid limitation time series. In version 8.0 the workaround is a bit more convoluted. You could mimic this with a self-consumption profile that acts as a stand-in for the losses in ramp-up (you would also need to simulate, then post process, create the load profile, then simulate again), but that is less practical as a workaround.

The production is mainly determined by the system capacity (10.32). The "number of sheds" = number of rows is only used for shadings calculations. Increasing the number of rows means that for a larger proportion of rows the row-to-row shadings will be present. This is why the production decreases, because shadings are a bit larger.

It is easier to transform fixed tilt structures to trackers in the 3D scene, using the Transform menu. The other way around can be more of a hassle. The wind stow option is a good option. it necessitates however to import weather data from a file in which you prepare a wind speed time series > some number. Another option is setting the tracker limit angles to e.g. min X and max X+1° if you are okay to fix the tracker to this 1° range. X and X might work too, though I would double check the output with the X, X+1 to make sure it is consistent.

yes this is because of the ratio of width and pitch (GCR) which ultimately controls the tracking algorithm. In your case the GCR is .5. which explains that these two modifications are equivalent (approximately). I would still suggest the remove 1 cm option as better since it mimics most correctly what pvsyst does and is more general to other GCR ratios.

To compare with baseline pvlib, I would rather remove 2 cm to the "Sensitive width". Might be 1 cm, I am not 100% sure if 2 is double counting.

There is indeed a baked-in 1 cm addition to the effective width of the tracker (both sides) when using backtracking in PVsyst. This is meant to account for possible inaccuracies in placement. When this was implemented, it was expected that such precautions (leaving a margin of error) are applied in the field. Probably it is still the case?

Hi, LID is a degradation pathway, which you can see as a definitive change in the module performance. It occurs in the first hours of exposure to sunlight, but then the effect remains. Degradation is modeled as a fixed ratio for the whole year, but in reality this loss should increase throughout the year. This is why we choose the mid-year mark as representative for the yearly degradation loss factor. Hence the 50% applied on the first year. Module array mismatch loss is different from degradation, you find its value in "Detailed losses > Module quality, LID, mismatch"

As you can see in the frames above what you have highlighted ("Number of rectangle-strings"), on your table there is a non-integer number of partitions. This means that either your tables are not consistent with the string length (can be an integer multiple or a simple fraction), or the length 31.75 is not exactly correct as a string length. The difference in length you are seeing is probably just the 0.54 and 0.34 remainder of the partitions that has shifted the partitions on the table. If your tables are just a multiple of a string length, the easiest is to use "Number of rectanlge-strings" on the tables to simply divide the string in the correct number of partitions.