laurahin

As a follow-up question regarding bifacial modules in a vertical orientation: Will PVsyst eventually know to treat a vertical bifacial module as having two "front" sides, such that near shading is computed for both sides? In recent tests, I found that the only shading I could put on the back side of the module came from the standard bifacial setting "rear shading." If I set this to zero, there is no near shading on the back side of the modules even though it occurs on the front. (This shading comes from the neighboring rows of modules, not shading objects.) Nevertheless, the "rear" POA irradiance is always lower than the front side irradiance, giving an asymmetry for front and rear irradiance, even on clear days. This I cannot explain. I do see that treatment of vertical modules is mentioned in the PVsyst v. 8 documentation, but it's not entirely clear what this will include. Modeling vertical module configurations seems to be an important development now. Thanks!

This turns out to be a "feature," not a bug: When you first open the project, PVsyst shows the tilt of the first tracker in the "Orientations" tab, but after you run the simulation, that value changes to the average. This was not the case in 7.3.

Hi, A colleague put together a shading scene using a PVcase pvc file that includes topography. When I open the project (after import), Orientation shows an average axis tilt of 3.1deg. My colleague's report shows 0.3deg. When I regenerate the report, it says 3.1deg, but when I rerun this variant, both Orientation and the report say 0.3deg. What's happening? Note that I have "Tracking: maximum axis tilt spread" set to 30deg and "Max. tilt axis for the Bifacial 2D model" set to 5deg; "Field type" is "Tracking, tilted axis." There is definitely N-S slope. In the image, one grid cell corresponds to about 72m. All runs give essentially the same energy output (within rounding error). First Orientation image is before run, second is after. Thanks, Laura H.

It turns out that these error messages don't appear until we select one of the graphs in the second illustration above, which is even more confusing. This all started because we get the following message when we first open the PAN in PVsyst. Perhaps this message should be in orange, not red, since the guidance is to "consider" a change and PVsyst will actually run. It was when we started to follow up on this message that the other errors appeared.

Hi, We got a new PAN file from a manufacturer, and after importing it, get the message "The model is not yet computed" under "Model summary" in the "Basic data" tab of the module info. The specific error is "Please define/check Rshunt and Rserie in the 'Model Parameters' tab." Given that Rshunt and Rserie have been supplied, I have to assume that the values break some rule in PVsyst, but we haven't been able to figure out what. The values _are_ a little strange: Rshunt = 12,000 and Rserie = 0.085. We're going back to the manufacturer for clarification, but if they stick with these values, is there any way we can get PVsyst to run, e.g., changing some hidden parameter? I can see a couple that might be relevant, but I don't know which is the right one or how dangerous the change might be. Thanks! Laura

I'm interested in calculating P-75, P-90, and P-99 values for PVsyst estimates. I looked at the help page on this subject (https://www.pvsyst.com/help/p50_p90evaluations.htm), and found that the only sources of uncertainty discussed in detail are related to input meteo data -- interannual variability, error in satellite data, etc. These are all things that the user can look up/calculate and apply to the PVsyst output themselves, externally to the PVsyst run. The part of the uncertainty that we're missing is that related to the PVsyst model itself. Could you supply some information about that? Clearly the full uncertainty is related to the quality of the inputs in addition to the uncertainty in model assumptions and algorithms, but it should be possible to estimate the magnitude of all of these effects independently (and I would hope that the uncertainty of the algorithms is checked every time an update is made, or there's no basis for making the update). In terms of the uncertainty of the inputs, you would just need to translate these uncertainties to the outputs, not estimate how bad people's input values are in the first place. Any information you could provide would be helpful. At the moment, IE's are guessing based on "experience" and comparisons to real systems, where errors in measured irradiance, deviation of construction from the engineering design, performance of trackers, etc., come into play. Thanks!

Actually, the "diffuse integrals" are also being recomputed every time, regardless of whether I'm running a batch or not, apparently just because something changed somewhere in the configuration. I don't want that to happen either, because we are using all trackers in the diffuse shading calculation. Is there any reason we can't just be happy with the existing shading if the shading scene hasn't changed?

According to I should be able to install 7.4.5 while keeping 7.4.6. However, when I try installing 7.4.5, I get this message saying that I need to uninstall 7.4.6 first: What gives? I need 7.4.5 to update an older project and am not too excited about repeatedly installing and uninstalling different versions. Thanks, Laura H.

Hi, This might be considered a feature rather than a bug, but it's still a problem. I am rerunning a project in PVsyst 7.4.6 that had previously been run in 7.4.5. Despite the electrical loss/shading error in 7.4.5, this run remains our required reference. I would therefore like to keep the 7.4.5 shading scene that creates the electrical loss error. According to the version log, a change for 7.3.2 was Shadings: PVsyst now suggests recomputing shading factor tables if they have been computed with an older version and for 7.4.2 was Shadings: shading factor tables now remain valid if no changes have been made to the shading scene This does seem to be the case when I rerun the variant, but when I implement a batch run, the shading scene is immediately recalculated. Is there any way to stop this from happening? If not, this is a feature I'd like to see. Thanks, Laura H.

This is a known problem with v. 7.4.5 that has been corrected in 7.4.6. There should be many other posts on this topic on the forum.

I had this same problem with batch output files. There is data in every column A, but sometimes also in B or C.

Bummer. It seemed like a good idea at the time.

Could you explain what "Trackers with shadings: the partition model for electrical shading losses now considers the bottom row of cells" means? Thanks.

We haven't seen large changes in the electrical loss yet in our (admittedly limited) use of v. 7.4, which includes variants with significant terrain. Is it possible that the differences as great as 3% aren't attributable to the modified shading loss algorithms per se but to automatic selection of a different diffuse shading reference tracker when rerunning in the higher version? We definitely have seen elect. loss differences that great depending on the location of the reference tracker in an array.

Say you have an array with two different module types, same racking and orientation, but different module sizes. Is the difference in backtracking behavior caused by the modules having different lengths taken into account when transposition is calculated for this array? If it wasn't for the size difference/backtracking, the modules would all face the same way. Thanks!