Discrepancy of shade losses between the initial simulation and the first re-run on the same layout

[akyle]

I've started to notice a consistent discrepancy in my shade loss values (both near shading and electrical shading losses) after going back into the shade scene and re-running the table. This has happened for both tracker and fixed tilt systems where I create the shade scene, run the simulation, go back into the shade scene and move 1 table off to the side and right back to its initial position, and then re-run table/simulation and the losses are different by about 0.2-0.4% cumulatively. 

I'm not sure why there is a discrepancy here because I am not changing anything about the shade scene, essentially just rerunning the same exact layout. I've also noticed that the discrepancy will only happen once. If I do the same process 2/3/4 more times, it gives the same result as the first re-run. It seems there is just a bug in the initial simulation and after that the results are solid.

I've tested this on version 7.2.12 and 7.2.14 and the same bug seems to be present. Does anyone have a theory or explanation for this?

[tpant]

Hi PVSyst team,

 

Any updates on the issue above. I am seeing the same issue with my runs where the initial run gives one yield values, then going in and moving a table slightly and bringing it back to the exact same spot ( and virtually no other changes to the model), makes the yield change erratically. Biggest swing I have seen in values has been 1.4%, this is really weird and can have major impact in modelling outputs.

Can you please provide an explanation of this issue? curiously after the first time of yield change the yield does not change thereafter and stays the same.

 

[Michele Oliosi]

Hi ! Thanks for reporting this issue. We will study what is going on.

Can you try deactivating the multithreading ? We had a few cases where the multithreaded calculation was leading to small bugs. If you can confirm whether the situation improves it will help us better locate the issue.

If you can send us an example project with that issue that would be great as well (Main window > File > Export project).

[akyle]

I have not gotten a chance to test your theory on multithreading, but wanted to go ahead and provide an example project for you. I've exported a project with 2 variants in the project folder: VC0 was created first and has the bug in it; I then created a copy of the variant, and did what I described above and the near shading loss/electrical shading loss increased by a combined 0.55%, as shown in VC1. It's not letting me upload a zip folder on this thread though, is there another way I can send it to you?

Also, I thought it was worth noting that my suspicion is that it may have something to do with the .csv ground data in the shade scene because I was not able to recreate the bug without adding the surface in.

[Michele Oliosi]

@akyle

you can send your project to support@pvsyst.com ! thanks in advance

[Michele Oliosi]

We have found and corrected one bug in the following case:

• Create a variant from scratch

• Set a tracking orientation with backtracking

• (Set up the system – can also be set later)

• Add a shading scene: import it from a .PVC and click OK

• In the Near shadings window, when prompted with the choice, select “With backtracking”

• Compute the table: the shading factors will behave as if backtracking was not activated

• Simulate: results with too many shadings

• Recompute the table: the shading factors are now correct

• Simulate: consistent results

Please let us know if the error does not correspond to the above procedure, especially the part in yellow. The error in the case above should be corrected in the next patch v7.2.17