Niklas

Hi Mikio, thanks for your answer. I am looking forward to your edit regarding the effects on the inactive areas. For the negative yield reduction, I attached my test-file below. Kind regards Niklas negative_yield_losses.pvprj

Hi all, I got a rather specific question regarding the shading analysis so this might not be for everyone. During the design process of a solar facade our architect got the idea to maybe tilt individual modules to get a more interesting looking facade. Now I want to investigate the influence of shadows due to different tilt angles of nearby modules on the yield using the shade frequency tool (see following picture). While trying different tilt angles, a question arose for me. How is the inactive area (e.g. the module frame) of a solar module taken into account when calculating power losses due to small shadows on the edge of a module? PV modules made for facade-integration are often frameless and manufactures of those modules therefore use the minimal frame thickness parameter of 1 mm in the PV*SOL database. In reality a small inactive edge of usually 10 to 20 mm still exists. Let's say a shadow is hitting this inactive edge without reaching the solar active part of the module. Would PV*SOL still calculate the module as partly shaded? Of course this example is a quite theoretical question. In my specific case I wonder, whether the small but strong shading on the edge of some modules is weighting heavier in the simulation than it does in reality. A shadow on the inactive edge area of a solar module would in reality not influence the yield at all. I would love to get some insight into how PV*SOL handles this! Also, while trying some things in a different project, I got a very interesting result for the "yield reduction due to shading" in the simulation results tab. How is PV*SOL allowing a negative yield reduction due to shading? So, a negative yield reduction would be a "gain in yield due to shading" ... That doesn't sound right to me. Did I encounter an error? I always use the latest version of PV*SOL. If needed, I can certainly provide the file since it was only a test project anyway. Many thanks in advance! Niklas

Hi Martin, thank you very much. That was just the right hint for me to spot my mistake . As I mentioned before, I had to combine weather data from multiple weather stations in relative close proximity. I worked on a relative complex python script, to concatenate and convert everything into one file readable by PV*SOL. My mistake was that I haven't payed attention to the format of the different timestamps. While some data was saved under a system time, other data was saved in the UTC format. In summertime I got an offset of +2 hours on days, where I had to calculate the average with the UTC data. I quickly aligned my timestamps and voilà ... everything is working fine. I guess the core message of my question is: Folks, keep an eye on your timestamps while merging different data sets . Again, thank you very much. Kind regards, Niklas

Hi @developer_mh, I don't really understand what you mean by that. How are these two parameters linked? And why should the simulation behave differently whether or not I payed attention to converting summer and wintertime? I get the same error message as @Endika: "MinuteSplitter: Input data and clear sky data are not sync.". When I import my hourly weather data file into PV*Sol, everything is working fine. I tried to simulate and everything works as intended. But when I switch so synthesized minute values, I get this error message. I tried out check out my data visualy as you discibed, but to my untrained eye I think that it looks in sync. I have to admit that my weather data is kind of stiched together, since I had to combine the data of different weather stations. Could you maybe have a look on my weather data and tell me what I have been missing? Thanks in advance! new_weather_data_2022.dat Kind regards Niklas

Hallo Martin, vielen Dank für die schnelle Rückmeldung. Freut mich zu hören, dass wenigstens die Simulationsergebnisse nicht beeinflusst werden. Viele Grüße Niklas

Hallo, in meiner Simulation eines Einfamilienhauses mit Balkonanbau sind mir Fehler beim Schattenwurf aufgefallen, die ich mir so nicht erklären konnte. An der Südfassade des Hauses sollen auf zwei Etagen jeweils zwei überdachte Balkone entstehen, welche ich in der Simulation mit Vordächern umgesetzt habe. Als tragende Stützpfeiler sind an den Ecken kleine "Schornsteine" verwendet worden. Die Balkonbrüstung beider Balkone soll in dieser Simulation aus PV-Modulen bestehen. Dafür habe ich die Module in einem ca. 90° Winkel aufgeständert. Zu erwähnen ist vielleicht noch, dass durch umliegende Bäume ab und zu eine größere Verschattung der Balkone entsteht. Bei genauerer Betrachtung des Schattenwurfs der gesamten Balkonkonstruktion fallen mir hier Fehler auf. Oder zumindest Stellen, welche unverschattet sind, obwohl offensichtlich kein direkter Lichteinfall diese Flächen beleuchtet. Im animierten Tagesverlauf des Sonnenstandes treten diese Fehler an mehreren Stellen auf. Um das Problem besser zu visualisieren habe ich hier zwei Bilder (Sonnenstand vom 21.06.17, 11:00 und 17:00 Uhr) beigefügt. Ich hoffe, dass ich mein Problem hier verständlich beschrieben habe und nicht eine einfache Lösung übersehen habe. Ich danke schon einmal im Voraus für Ihre Hilfe. Mit freundlichen Grüßen Niklas