developer_mh

Hallo Robert, vielen Dank für die hilfreichen Anmerkungen. Punkt 1 ist sehr interessant, das werden wir uns einmal ansehen. Punkt 2 haben wir auch schon auf der Liste. Der Ladewirkungsgrad ist zwar auch in PV*SOL abhängig von der Ladeleistung, aber wohl tatsächlich ein wenig zu optimistisch angesetzt. Gute Hinweise, danke nochmal! Viele Grüße, Martin

Hallo Ralf, der prozentuale Wert, der in der 3D-Visualisierung auf den Modulen dargestellt wird, bezieht sich nur auf die Reduktion der Clear-Sky- (oder Schönwetter-) Strahlung. Es fließt damit der standortabhängige Verlauf der Sonne mit ein, aber nicht die tatsächlichen Klimadaten. Die Ertragsminderung durch Abschattung hingegen berücksichtigt wirklich alles, also die tatsächlichen Klimadaten (Direkt- und Diffusstrahlung), Änderung der Modultemperatur durch die Abschattung, Mismatch-Verluste dadurch, dass die Module ungleich abgeschattet werden etc. Die Prozent-Werte in der Planung sind somit nur ein schnell verfügbarer Hinweis für den Planer, bei welchen Modulen eine höhere Abschattung zu erwarten ist. Wie hoch die tatsächlichen energetischen Verluste sind, kann nur die Zeitschritt-Simulation am Ende der Planung zeigen. Viele Grüße, Martin

Hi Ricardo, you can find the IAM under "Additional parameters": Kind regards, Martin

Gerne

Hi Nicolaas, I will inform the database team that this inverter is missing. You can also do so by writing them an e-mail (database@valentin-software.com), if you encounter another missing inverter or module in the future. In the meanwhile you can duplicate an existing inverter from Schneider and update the electrical properties according to the data sheet: https://solar.schneider-electric.com/wp-content/uploads/2020/08/DS20200812_CL36.pdf You can use it then in your simulations. Kind regards, Martin

I'd say you will have to extract the climate data (csv export after the simulation, then take the irradiation and temperature values). In a spreadsheet application, manipulate the ambient temperature as desired, make a new climate data file out of it, and the re-import it into PV*SOL. Here's a description of how the file format for climate data import has to look like: https://help.valentin-software.com/pvsol/2020/pages/system-type-climate-and-grid/meteosyn/#options But it will be a really rough work around, and I am not sure if you want to recommend that. Kind regards, Martin

Hi Ian, usually we use climate data of a long period of time, 10 years or more, in order to represent a typical meteorological year. More on this topic can be found here: https://help.valentin-software.com/pvsol/2020/calculation/irradiation/climate-data/ If you want to simulate with weather data from only one year you would have to import these data first. In PVGIS you can get single years of irradiation and temperature data if I am not mistaken. Then you prepare a custom weather file that you can import into PV*SOL: https://help.valentin-software.com/pvsol/2020/pages/system-type-climate-and-grid/meteosyn/#options Hope that helps, kind regards, Martin

Hallo C. Drexel, bei der DC-Zwischenkreis-Kopplung ist das Speichersystem im DC-Zwischenkreis des Wechselrichters angeschlossen, also zwischen MPP-Tracking-Einheit und DC/AC-Wandler. Im Zwischenkreis herrscht eine konstante DC Spannung, oft z.B. 400 V. Der Anschluss bezieht sich damit also tatsächlich auf ein physikalisches Gerät, und man kann nicht einen Batterie-Speicher an mehrere DC-Zwischenkreise gleichzeitig anschließen. Hier nochmal der Link zu unseren Hilfeseiten zu dem Thema: https://help.valentin-software.com/pvsol/2020/berechnungsgrundlagen/batteriesysteme/#art-der-kopplung Und hier noch eine Grafik des pv magazines, das die verschiedenen Kopplungsarten auch ganz gut erklärt: Beste Grüße, Martin

Hallo, vielen Dank für die Projektdatei. Die Batterie wird im Winter in der Regel nicht geladen, da die Deckung des Verbrauchs eine höhere Priorität hat. Geladen wird die Batterie erst dann, wenn nach Deckung des Verbrauchs noch genügend PV-Leistung zur Verfügung steht. Ausschlaggebend ist hier bei der DC-Zwischenkreis-Kopplung die PV-Leistung des Wechselrichters, an dem das Batterie-System angeschlossen ist - in Ihrem Fall ist das der 1. Wechselrichter. Die Netzeinspeisung in diesen Perioden kommt dann durch die anderen Wechselrichter zustande, so dass es auf den ersten Blick vielleicht so aussieht, als würde PV-Leistung ins Netz eingespeist werden, obwohl man damit doch Batterien laden könnte. Warum der Autarkie-Grad im Vergleich zu den anderen Projekten niedriger ist, kann ich leider anhand dieses einen Projekts nicht beantworten. Kannst du mir die anderen Projekte, bei denen der Autarkiegrad höher ist, auch noch zukommen lassen? Beste Grüße, Martin

Hallo Julian, wenn das Programm meldet, dass fehlende Informationen nicht ermittelt werden konnten, handelt es sich in aller Regel um das Land des Standorts. In diesem Fall konnte es den Standort nicht ermitteln, da der Längengrad das falsche Vorzeichen hatte. Also streng genommen ist es ja das richtige Vorzeichen, nur muss man es für den Import in Meteosyn anders herum eingeben. So klappt's: Tzoukri 39.1334,-20.5429,40,-2,-30 ... Viele Grüße, Martin

Hi Manuel, right now there is no specfic installation type for floating PV mounting systems that would lead to 1 to 3°C lower temperatures. The closest option right now would be the open space mounting: In addtion you can set the albedo value to water: https://help.valentin-software.com/pvsol/2020/options/#simulation https://help.valentin-software.com/pvsol/2020/calculation/irradiation/ground-reflection/ But we will add an installation type for floating PV in the one of the next releases. Kind regards, Martin

Hi Ricardo, these reflection losses are mainly influenced by the IAM value (incidence angle modifier) that is part of the module data. Using this value we calculate the reflection as decribed here: https://help.valentin-software.com/pvsol/2020/calculation/pv-modules/reflection-in-module-plane/ Also, see these threads on the same topic: So, in order to compare your two results and explain the differences, we would need the two projects with the two modules. If one of those modules was created by yourself, check the IAM value of that module, if it is the same as the other module. Kind regards, Martin

Hi Frido, thanks for the feedback. I can understand the frustration. But I want to come into the defense of the hotline team, since the work around was not known before. So they couldn't inform you of it. We are sorry for all the work you had to put into the project. Best wishes and kind regards, Martin

Hallo C. Drexel, am einfachsten wäre es, wenn wir die Projektdateien bekommen könnten. Du kannst sie hier im Forum als private Nachricht an mich schicken. Danke und beste Grüße, Martin

Dear all, in the current version, PV*SOL premium 2020 R9, there is a bug when simulation large PV systems or inverters with plenty of MPP trackers that prevents these module area specific numbers to show up in the results section. The bug will be fixed with the upcoming release. In the meanwhile you can use this work around. Open the file C:\Users\USERNAME\Documents\Valentin EnergieSoftware\PVSOL premium 2020\PVSOL.ini and adjust the fields "MaxNumberOfInvertersForResults" and "MaxNumberOfMppsForResults" in this row: <Results SaveHourlySimulationResults="False" SaveOneMinuteSimulationResults="False" SaveIVCurves="False" CalculateYieldLossDueToShading="True" MaxNumberOfInvertersForResults="10" MaxNumberOfMppsForResults="40" FeedInModel="1" WithIvCurves="0" IvCurvesMppTrackerNr="1" /> The numbers must be higher than the corresponding quantities in you project. MaxNumberOfInvertersForResults="20" MaxNumberOfMppsForResults="100" Hope that helps, and sorry for the inconvenience caused, Martin

Hi Andras, in the current version, PV*SOL premium 2020 R9, there is a bug when simulation large PV systems or inverters with plenty of MPP trackers that prevents these module area specific numbers to show up in the results section. The bug will be fixed with the upcoming release. In the meanwhile you can use this work around. Open the file C:\Users\USERNAME\Documents\Valentin EnergieSoftware\PVSOL premium 2020\PVSOL.ini and adjust the fields "MaxNumberOfInvertersForResults" and "MaxNumberOfMppsForResults" in this row: <Results SaveHourlySimulationResults="False" SaveOneMinuteSimulationResults="False" SaveIVCurves="False" CalculateYieldLossDueToShading="True" MaxNumberOfInvertersForResults="10" MaxNumberOfMppsForResults="40" FeedInModel="1" WithIvCurves="0" IvCurvesMppTrackerNr="1" /> The numbers must be higher than the corresponding quantities in you project. MaxNumberOfInvertersForResults="20" MaxNumberOfMppsForResults="100" Hope that helps, and sorry for the inconvenience caused, Martin

Hallo an alle, dank der Dateien von Tom konnten wir das Problem schnell finden. Wir werden diesen Fehler mit der nächsten Version beheben. Hier der Workaround für alle: In der Zwischenzeit würde Abhilfe schaffen, in der Datei C:\Users\USERNAME\Documents\Valentin EnergieSoftware\PVSOL premium 2020\PVSOL.ini die Felder "MaxNumberOfInvertersForResults" und "MaxNumberOfMppsForResults" in dieser Zeile zu ändern: <Results SaveHourlySimulationResults="False" SaveOneMinuteSimulationResults="False" SaveIVCurves="False" CalculateYieldLossDueToShading="True" MaxNumberOfInvertersForResults="10" MaxNumberOfMppsForResults="40" FeedInModel="1" WithIvCurves="0" IvCurvesMppTrackerNr="1" /> Für dieses Projekt passende Werte sollten bei 20 und 100 liegen, also MaxNumberOfInvertersForResults="20" MaxNumberOfMppsForResults="100" Beste Grüße, Martin

Hallo Tom, wäre es möglich, uns ein Projekt zur Verfügung zu stellen, bei dem dieser Fehler auftritt. Es scheinen auch andere Anwender betroffen zu sein, aber bisher haben wir den Fehler noch reproduzieren können. Das Projekt kannst du hier im Forum per privater Nachricht schicken, danke. Beste Grüße, Martin

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