developer_mh

Hey Reint, thanks for the projects. Let me explain the two main aspects here. In the energy balance, the losses due to module independent shading can in fact be different depending on the configuration. I know this sounds counter-intuitive, but it has to do with some logic that we use to create the energy balance. Before the simulation, the smallest common diffuse shading value is determined for each module area. In the simulation in the radiation processor, this causes the module-independent shading. This minimum diffuse shading, i.e. the smallest common diffuse shading value, is subtracted from the diffuse shading values of the individual modules before the simulation. This enables us to determine which part of the diffuse shading is the same for all (module-independent) and which part differs from module to module (module-specific partial shading, in which case direct shading is also included). In any case, nothing is lost in the simulation, it is only evaluated differently depending on the situation. I would say this is a very low loss of energy in a DC/DC converting device. According to the database the P801 power optimizer has a efficiency curve like this: In a wide range the efficiency is around 98.5%, which in turn explains the energy loss of 1.66%. This energy loss must be made up for in shading situations where the power optimizers can perform better than normal systems. As pointed out, the use of SolarEdge optimizers is not per se a good idea unless you have shading situations where these devices really can outperform normal systems. The Huawei performance in these projects is good, that is true, but I can't see any sign of overestimation. It always depends on the shading and on the configuration. There are a number of threads in this forum and also conference papers that cover that topic. It is surely an interesting one, and it shows that you should always calculate those things yourself when you plan a PV system. So, as conclusion, I'd vote for the option "accurate simulation" Kind regards, Martin

Hi Reint, as Vishnu pointed out already: It would be good of you could provide the two project files (per private message) so that we can have a detailed look at them and explain the differences in the energy balance. Kind regards, Martin

Hallo Willi, könntest du uns eins der Projekte zur Verfügung stellen, deren Simulation nicht durchläuft? Du kannst sie hier im Forum per private Nachricht senden. Welche Version von PV*SOL nutzt du? Beste Grüße, Martin

Hi Reint, yes, take a look here: Hope that helps, kind regards, Martin

Hi Peter, could you send a project file where that happens, please? You can send it by private message here in the forum. Thanks a lot, Martin

Hi Nicolaas, there is no user friendly way to see that. If you are willing, you could unzip the pvprj file using 7zip and then take a look at the file "Project.xml". There you will find a node that looks like this: <ProgramsUsedToEditProject> <Program>PV*SOL premium 2020 (R9)</Program> </ProgramsUsedToEditProject> If that seems too complicated, you can send a file and I will take a look for you. Kind regards, Martin

Hi MoYas, there are a several things to consider. 2016 Trina Solar TSM-335-DD14A modules have a nominal DC power of 675 kWp. The SunGrow SG125HV has 125 kW nominal power and 175 kW max DC power. So you will have to take at least 4 inverters. Then you would have 504 modules per inverter. One approach would be to pack as much modules in a serial string as possible. And there you will encounter the next issue. The Trina module is designed for 1000 V max system voltage, but the inverter is at 1500 V. When configuring the PV array you will see that it is impossible to find a number of modules in series that will satisfy both constraints of MPP voltage and of max open circuit voltage. See for example the configuration check for 16 x 30 modules: The MPP voltage range is good, but the modules have a far too high max OC voltage. If you decrease the number of modules in series to 18 or 19, the max OC voltage is ok, but then the MPP voltage range is too low: So there is no way to configure these specific Trina modules to this specific inverter, unless you alter the configuration options (i.e. allow modules not to reach the MPP voltage limits). If you use 1500V modules from Trina, e.g. the DE15M with 395 Wp, you can find a solution where 28 modules fit in a string: Hope that helps, kind regards, Martin

Hallo remex, die Abregelung kann man auf der Seite "Anlagenart, Klima und Netz" bei AC-Netz einstellen. Die Eingabe erfolgt in Prozent der installierten DC-Leistung. Wenn AC-seitig also max. 30 kVA eingespeist werden sollen und man hat 44 kWp PV auf der DC-Seite installiert, müsste man hier 68% eingeben. Damit E-Auto und Wärmepumpe auch noch versorgt werden können, bevor der WR abregelt, sollte die Abregelung am Einspeisepunkt gewählt werden. Beste Grüße, Martin

Hi Robert, the automatic cabling option is for cabling the DC side only. If you use micro inverters, there is no DC side to cable, hence the message. The reason why there are two modules left unwired is hard to tell, could you tell us more about what exactly you did to wire the micro inverters? Kind regards, Martin

Hallo K24, das Wärmepumpen-Lastprofil, das wir derzeit in PV*SOL hinterlegt haben, ist nicht PV optimiert, nein. Aber in der neuen Version von PV*SOL (premium 2021 R1), die Ende des Jahres auf den Markt kommen wird, haben wir die dynamische Simulation von Wärmepumpen integriert - auch mit PV-optimiertem Modus! Beste Grüße, Martin

Hallo Julian, bei der Aufteilung von Großprojekten in kleinere Teilprojekte gibt es kein offiziell empfohlenes Vorgehen. Im Prinzip funktionieren beide Vorgehensweisen, die du schon angerissen hast. Da man aber in PV*SOL keinen "Großprojekt-Skalierungsfaktor" eingeben kann, müsstest du alle Erträge, Verluste und sonstigen Zahlen eigenhändig mit diesem Faktor verrechnen. Empfehlen würde ich daher eher, die Anlage in Teilprojekte zu zerlegen und einzeln zu simulieren. Dann bekommst du auch zu jedem Teilprojekt einen Projektbericht. Zu 2.: Nein, das Einlesen einer variablen Topologie geht leider derzeit (noch) nicht. Man kann aber einzelne Freiflächen mit einer Neigung versehen und darauf dann die Anlage platzieren. Wenn das Gelände nicht sehr hügelig ist, bekommt man so eine gute Annäherung realisiert. Beste Grüße, Martin

Hallo Markus, die Abschattung in der 3D-Visualisierung wird in 10min-Schritten berechnet und dann in Form von Stundenmittelwerten an das PV*SOL Hauptprogramm übergeben. Diese Werte werden derzeit auch noch bei der Minuten-Simulation verwendet. Wir arbeiten aber bereits an einer Folge-Lösung, bei der dann auch die Abschattung als Minutenwerte an die Simulation übergeben wird. Beste Grüße, Martin

Hi Muhammad, like timgreen said, the best way to go is to model it in another 3D application like Sketchup and import it then. A canopy like this is not possible with the built-in 3D design tools of PV*SOL. Kind regards, Martin

Hi Julius, our technical hotline staff found out that the model is already broken in the exported obj file: This might be related to a surface normal that is pointing downwards instead of upwards, or an area that is not completely closed. They recommend to compare the right and left attic as precisely as possible in order to find differences in the model. Hope that helps, kind regards, Martin

Hi Julius, sometimes there are problems with attics of imported models. Could you provide the model so that our technical hotline can have a look at it? You can send it here via private message or directly to hotline@valentin-software.com Thanks a lot in advance, Martin

Dear Cezary, thanks a lot for the project file. I had a look into it and found a bug, unfortunately. It is not related to Hoymiles inverters specifically, but with this specific configuration that i sused in your project. The bug will be fixed with the next release after the upcoming release PV*SOL premium 2020 R9 (it is on the way to be published already, so it is too late for the bugfix, I am afraid). I will send a modified project file in a private message to you so that you can simulate it. There I modified the configuration a bit as you will see, just to avoid this specfic bug. Hope that helps, kind regards, Martin

Hallo Veronika, danke für die Projekt-Datei. Um die verschiedenen Effekte, die bei der Wirtschaftlichkeitsberechnung eine Rolle spielen, auseinanderzuhalten, habe ich erstmal die Moduldegradation auf 100% (also keine Degradation), den Kapitalzins auf 0% und die Preissteigerungsraten auf 0% gesetzt. Die Abrechnungsjahre in der Cashflow-Tabelle beginnen immer am 01. des Inbetriebnahme-Monats. Wenn das Datum der Inbetriebnahme der 07.08. ist, ginge das Jahr 1 in der Cashflow-Tabelle also vom 01.08. bis zum 31.07. des Folgejahres. Das bedeutet in diesem Beispiel zweierlei: Die ersten sechs Tage des August gehen für die Abrechnung verloren (und werden auch nicht hinten angehängt) Im Jahr 21, also nach Ablauf des Betrachtungszeitraums wird nur noch die Einspeisung des Restjahrs vergütet, also vom 07.08. bis zum 31.12. In Zahlen sieht das so aus (sorry für das Pfund-Zeichen, ist auf meinem Rechner noch so eingestellt), hier fehlen die ersten sechs Tage des August Und hier wird nur noch die Einspeisung des Rest-Jahres vergütet: Wenn man jetzt die Moduldegradation mit rein nimmt, wird die jährliche Einspeisevergütung natürlich von Jahr zu Jahr geringer: Und wenn man dann den Kapitalzins (Umlaufrendite) wieder auf 1% setzt, wird die Einspeisevergütung noch geringer, da sie ja dann in Zukunft weniger wert ist: Die Preisänderungsfaktoren spielen dann eben auch noch mit rein, aber ich führe das mal nicht weiter aus, das Prinzip wird ja klar. Ich hoffe, das hilft ein wenig beim Verständnis der doch komplexen Materie. Wenn du noch Fragen hast, gerne fragen. Beste Grüße, Martin

Hallo Veronika, wenn die Werte im zweiten Jahr im Vergleich zum ersten Jahr steigen, hat dies in den meisten Fällen mit dem Inbetriebnahmedatum oder der Gültigkeit der Tarife zu tun. Um im konkreten Fall eine Antwort geben zu können, wäre es hilfreich, wenn du eine Projektdatei zur Verfügung stellen könntest, an der wir die Zahlen direkt nachvollziehen können. Du kannst sie gerne per privater Nachricht schicken. Beste Grüße, Martin

Dear Mahmoud, in PV*SOL we always model PV systems with batteries with two separate inverters, one for the PV and one for the batteries. However, in reality these two inverters can be combined in one product. Hope that helps, kind regards, Martin

Hi Cezary, could you provide more detail about what exactly happens? Also, it would be helpful if you could send us your program log files. You can find them at C:\ProgramData\Valentin EnergieSoftware\log If you have a project file that you could send me via private message, it would be even easier to identify the problem. Thanks ans kind regards, Martin

Hi JL, a tax bonus like this can not be calculated by PV*SOL, I guess you would need a tax software for that. Kind regards, Martin

Hallo Rixxe, den kurzen Pfosten kann man noch mit Hilfe eines sehr schmalen Schornsteins nachbilden, aber die Stromleitungen dann nicht mehr. Es gäbe aber die Möglichkeit, das gesamte Haus mit Aufbauten in einem externen 3D Programm (z.B. Sketchup) zu modellieren und dann in PV*SOL zu importieren. Dann hätte man auch die Leitungen drin. Beste Grüße, Martin

Hallo nevs, eine solche Regelung ist uns bisher von SolarEdge nicht mitgeteilt worden, aber um sicher zu gehen, würde ich empfehlen, einfach mal SolarEdge zu kontaktieren. Wenn du eine Antwort erhalten hast, würde uns das hier im Forum sehr interessieren! Vielen Dank und beste Grüße, Martin

Hey Reint, perhaps you tried the following, I just wanted to make sure that you checked this option in order to see the unavailable Autarco inverters as well: Kind regards, Martin

Hi John, we re-developed, updated and unified the load profile features in version 2020, so unfortunately you can't edit some of the older load profiles from version 2019 or before. This applies to individual appliances and load profiles from day profiles. You can simulate those profiles without problems, however. Hope that helps, kind regards, Martin