Debbie

Yes, that's correct. The site I was working with had the trackers tilted on the terrain with different tracker heights and axis tilts. The custom diffuse tracker that I had selected in version 7.4.8 worked with the selection of adjacent masking trackers. But after importing the project to version 8.0.9 the masking selection did not select the adjacent trackers and I had trouble getting that to work.

Also, when I tried to switch it from "custom tracker" to "all trackers", it did not correctly save this change when running the model. The report still shows "custom tracker" and the shade losses are still lower than the prior model because that custom tracker is on an edge of the mask.

In version 8.0.9, I found that when I run a model from version 7.4.8 that had a good "custom diffuse" tracker selected, it is now not masked correctly (it is on the edge). Even if I go in in version 8.0.9 and select one that masks properly, after running it, it is on an edge again. See image below. This appears to be a bug with the custom diffuse tracker masking in version 8.0.9. Can this be fixed? It is not practical to always use "all trackers" for large arrays. The problem may occur specifically when the trackers are tilted on the terrain. This problem results in erroneous production jumps close to 1%, because the diffuse shade is only half accounted for. Thanks in advance for the help PVsyst.

Also, when I tried to switch it from "custom tracker" to "all trackers", it did not correctly save this change when running the model. The report still shows "custom tracker" and the shade losses are still lower than the prior model because that custom tracker is on an edge of the mask.

In version 8.0.9, I found that when I run a model from version 7.4.8 that had a good "custom diffuse" tracker selected, it is now not masked correctly (it is on the edge). Even if I go in in version 8.0.9 and select one that masks properly, after running it, it is on an edge again. See image below. This appears to be a bug with the custom diffuse tracker masking in version 8.0.9. Can this be fixed? It is not practical to always use "all trackers" for large arrays. The problem may occur specifically when the trackers are tilted on the terrain. This problem results in erroneous production jumps close to 1%, because the diffuse shade is only half accounted for. Thanks in advance for the help PVsyst.

Just to share, I was actually able to import it. .3DS format was better. I was able to run it, but it was very slow and hard to work with because it was so flow. I'll be trying with a more powerful computer in the future.

Hello PVsyst team, I'm trying to import a DAE file with a very large number of tables. There are about 22,000. So far it has been running without result for 15 minutes on the import step. Is there a maximum number? I'm wondering if I'll need to break up the array, and if so, into how many sections. Both for import, and also for running the shade scene. Also, is one format better than the other in this case...DAE or 3DS? This is to attempt to model Nextracker XTR...I know I can't get string mismatch, but I'm trying to see the row to row shade impacts. Not using TrueCapture. Thank you! -Debbie

If I select the "custom tracker" option, shouldn't that prevent it from using all the trackers in the calculation, regardless of the advanced parameters? (currently at 40 for mine). I will see if it happens again, now that I'm running a new model, and will report back.

Hi PVsyst team, In version 7.3.4 I am finding that computing the integrals for diffuse is taking about 6 minutes each time I run the model again (even if I don't change the near shading scene). Usually this doesn't happen when I set the reference diffuse tracker to a custom selected tracker. Is this a change in the new version? Thank you, Debbie

Thank you, I had to modify the inverter file, it was limited to only unity power factor. I was not expecting that when using this new inverter file.

Hi PVsyst team, In version 7.3.4, when I input a non-unity power factor, I am still getting 0 reactive energy in the loss diagram. Is this possibly a bug? Screen captures below taken from the same report. Also, in this same model, even though I chose a custom reference tracker for the diffuse calculation, it spent a long time (~8 minutes) calculating the diffuse integrals when running the model. I look forward to your response. Thank you.

This paper references a pending update to PVsyst that will address sub-hourly clipping. Is there an expected timeline for release of this update? Thanks very much, Debbie

Hi PVsyst team, I really appreciate the speed of the tracker shading analysis in this version, and the new interface for diffuse shade losses. However, I noticed that sometimes when the central tracker is selected, or I select a custom tracker, it does not automatically select the adjacent trackers for the "shading mask". See screen capture below. I have found that I need to try selecting a few different trackers until I get one where the mask includes trackers on both sides. If I run the model with the selection that does not include shading trackers on both sides, it significantly impacts the results. I'm not sure why this happens. Perhaps it has to do with the tilt of the trackers? These have variable N-S tilts because of terrain. Perhaps if the tilt between adjacent trackers varies too much they don't get selected? Thank you, Debbie (example where the selected tracker did not cause the neighboring trackers to be selected)

In V7.3.1 the notes on the report cover seem to be limited to one line. At least for my computer system. Can you check this for the new release? Thank you! -Debbie

Ah, I had to also redo the shading table calculation after changing the threshold, then after that it triggered the "computing the integrals for diffuse" while running the model. So it does seem to work the same with a non-backtracking array.