developer_mh

Hallo Tobi, Welche Module sind denn nicht korrekt in der Datenbank? Bei uns geben ja die Hersteller die Daten ein insofern können wir leider nicht jederzeit garantieren, dass alle Daten korrekt sind. Aber wenn wir wissen, um welche Module es sich handelt, können wir das den Herstellern so weitergeben. Ansonsten hast du das richtig gemacht. Das Modul kopieren, einen Leistungsoptimierer auswählen und die restlichen Eingaben so stehen lassen. Die Warnung bezüglich der Mismatching-Verluste kann man wahrnehmen und dann je nach Anwendungsfall ernst nehmen oder ignorieren Es entstehen durch unterschiedliche Stanglängen auf jeden Fall Mismatching-Verluste, dessen sollte man sich bewusst sein. Es empfiehlt sich auch, diese nach der Simulation in der Energiebilanz zu überprüfen. Aber wenn man sich dessen bewusst ist, und diese Verluste in Kauf nimmt, kann man die Warnung ignorieren, ja. Tutorials würden wir sehr gerne mehr machen, momentan fehtl uns leider ein wenig die Zeit dazu. Aber wir nehmen deine Anregung auf, danke dafür. Beste Grüße, Martin

Hi Niclas, yes, I think it has nothing to do with the PV*SOL version. Have you imported this exact file before and it worked? Or was it another file? Did you change anything else in your system? Kind regards, Martin

Hi Niclas, can you check if there is another process accessing these directories? E.g. do you have an antivir software where you could add an exception for that folder, just to test? Kind regards, Martin

Hallo J.Ackfeld, leider haben wir momentan keine "saubere" Lösung, um BHKW in PV*SOL zu simulieren. Eine unsaubere, aber ggfs. gangbare Lösung wäre, den Verbrauch um eine Grundlast von 10 kW zu reduzieren, wenn das das derzeitige Lastprofil überhaupt hergibt. Das ginge nur, wenn beim derzeitigen Lastprofil die Leistung von 10 kW nie unterschritten wird. Diese Reduktion der Last wäre dann sozusagen der Beitrag, den sonst das BHKW leistet, sodass sich die PV nur um den Anteil kümmern muss, der die 10 kW übersteigt. Konkret würde man das so machen, dass man das Lastprofil exportiert (nach der SImulation auf der Seite "Präsentation" in den csv-Export) Dann in Excel diese Datei öffnen und die stündlichen Verbrauchswerte herauskopieren (Jahreswerte und Monatswerte werden nich gebraucht), am besten in eine andere Excel-Datei. Dort kann dann die gewünschte Modifikation vorgenommen werden. Hier habe ich z.B. ein 1kW abgezogen und dann das Profil in Wh umgerechnet (*1000). Dieses neue Profil dann speichern (ohne die erste Spalte und ohne Kopfzeile), und dieses dann wieder in PV*SOL importieren, auf der Seite Verbrauch -> Neuer Verbraucher -> Lastprofil laden und importieren Ich hoffe, das hilft erstmal weiter. Ist leider eine etwas unkonfortable Lösung, die auch nicht in allen Fällen passt. Beste Grüße, Martin

Hi Niclas, since we haven't changed anything in the 3D model importer or the 3D environment, I believe that it is a coincidence that this error occurred only today. The error message says that some other process is accessing the files. Perhaps you can try to close all PV*SOL instances and then delete all folders inside C:\Users\{YOUR-USERNAME}\AppData\Local\Valentin EnergieSoftware\Temp\PVSOL premium 2019 Did you change anything else on your computer other than the PV*SOL update? Kind regards, Martin

Hi Tim, SolarEdge updated their configuration rules that describe which inverter can be connected to which power optimizers in which country etc. Our inverter configuration is now compliant with these updated rules and users will get hints accordingly. Hope that helps, kind regards, Martin

Hi Carlos, in order to debug this, it would be helpful if you could provide some more information. Which version of PV*SOL 2019 are you using? Can you send the log file "PVSOLpremium.log" ? It is located under C:\ProgramData\Valentin EnergieSoftware\log Also, please send a dxdiag file (hit Windows key, then type "dxdiag", hit enter and then choose "Save All Information"). You can also send these files in a private message. Thanks and kind regards, Martin

Hi Tim, the year that we simulate isn't a specific one. It is a general year, just the 8760 hours of one typical year at a given location. The climate data is taken from real years with a range of 10 to 20 or even 30 years and is compiled into a single typical meteorological year (TMY), that contains e.g. the January of 2006, the February of 2013, March 2014, and so on. See more on that topic here: https://help.valentin-software.com/pvsol/2019/calculation/irradiation/climate-data/#what-are-climate-data-sets-what-does-typical-mean-year-mean So, this single TMY is "yearless", so to speak. It stands for a typical year in the time range that is denoted in the climate data. Hope that clarifies the matter, kind regards, Martin

Dear Tim, yes, that is true. This is because we only simulate one year, and the calendar component that you showed in your screenshot needs a year to be set. 2014 is just an arbitrary value, a placeholder for any year, if you want. Sorry for the confusion, kind regards, Martin

Hi Juan, sorry for the late answer. Somehow I overaw this question.. right now it is not possible to simulate an offgrid system with DC coupled batteries, I am afraid. The offgrid logic that we implemented is based on the SMA products, so there is no DC option, sorry. Kind regards, Martin

Hi b_yilmaz, yes, you can achieve this by using the polystring feature. You can combine any thinkable configuration of modules together. https://help.valentin-software.com/pvsol/2019/pages/inverters/polystring-connection/ Hope that helps, kind regards, Martin

Hi Alex, yes, it is true, this option is missing right now. We will consider it for future versions. Right now you can export the project report as Word file and then add the desired graph manually. You can save all diagrams in PV*SOL by right clicking on them. Hope that helps for the moment, thanks for your feedback. Martin

Hi Alexclavijon, in order to debug this, it would be helpful if you could provide some more information. Which version of PV*SOL are you using? Can you send the log file "PVSOLpremium.log" ? It is located under C:\ProgramData\Valentin EnergieSoftware\log Thanks and kind regards, Martin

Hi RobS, here you can find more information on how to set P90 parameters: https://help.valentin-software.com/pvsol/2019/pages/financial-analysis/bankability-p50p90/ Please note that this option is only available for full feed-in PV systems. That is, if you have electrical appliances in your system, you won't see the P90 option. Kind regards, Martin

Hallo FXR, diese Einstellung kann beim AC-Netz vorgenommen werden: https://help.valentin-software.com/pvsol/2019/navigationsseiten/anlagenartklimaundnetz/#ac-netz Beste Grüße, Martin

Hi Lucija, there is some other process that is accessing our temp folders under C:\Users\EnercoSolardooEnerco\AppData\Local\Valentin EnergieSoftware\Temp\PVSOL premium 2019\ Please check if you can add an exception rule in your antivirus software so that this directory is not touched. Firstly, you can also close PV*SOL and delete all files and folders inside this temp folder. Kind regards, Martin

Hi Lucija, it seems that the problem occurs when you click on the IV curves tab in the PV module dialog. I can see that another process is accessing a file that we need to show the IV curves, that is why it crashes. One option would be to find out which process is accessing the file (e.g. an antivirus software?). Another option would be not to click on that IV curves tab when creating new modules. Kind regards, Martin

Hallo Mario, Negativwerte für Verbraucher gehen nicht, da hast du Recht. Mir ist aber ehrlich gesagt noch nicht ganz klar, welche Daten vorliegen, und was aus der Simulation mit der Altanlage herauskommen soll. Es gibt die Produktionswerte der alten PV in 15-Minuten Auflösung und den Jahresverbrauch des Haushalts, also ein Wert für ein Jahr? Ist dieser Jahresverbrauch abhängig von der PV-Produktion der Alt-Anlage? Beste Grüße, Martin

Hi Lucija, could you send the error report using the dialog you showed here? If you type in your name into the textbox "Where possible, please describe ...", I can see which error report was yours. Thanks a lot, kind regards, Martin

Hi Patrik, we would recommend to get the TMY data from PVGIS, this would be the most reasonable option to simulate a PV system: You can then transform the *.csv file into a *.dat file that you can import into PV*SOL, following these instructions here: https://help.valentin-software.com/pvsol/2019/pages/system-type-climate-and-grid/meteosyn/#create-new-location Unfortunately, you can't import longer periods than one year. If you want to simulate real years, you would have to import one *.dat file for each year and then simulate them separately. Hope that helps! Martin

Thank you, Vishnu, for answering!

Hi Vishnu, You are right, a module without reflection losses doesn't exist. And to our present knowledge it can't exist in future. The PV module data is entered into our database by the manufacturers, so they are responsible to provide the correct values. Or provide the values that represent their module in the best way possible. We calculate the reflection losses in dependance of the angle of incidence: https://help.valentin-software.com/pvsol/2019/calculation/pv-modules/reflection-in-module-plane/ Kind regards, Martin

Hi Vishnu, the first result that you show is the energy yield according to EnEV (German Standard "Energieeinspeiseverordnung") and is calculated with the (simple) formulas given in the standard. https://help.valentin-software.com/pvsol/2019/pages/results/energy-yield-for-enev/ The second result is the energy balance that is an output from our simulation core. https://help.valentin-software.com/pvsol/2019/pages/results/energy-balance/ So, if you want to have a "Nachweis" for the German EnEV, take the first results. If you want to have a detailed and validated simulation of your PV plant, take the second Kind regards, Martin

Hi Vishnu, we calculate the impact of the shading down to substring level. You can read more on that topic here: https://help.valentin-software.com/pvsol/2019/calculation/pv-modules/shading-due-to-nearby-objects/ We consider the diffuse shading to be equally distributed over one module. But we calculate it separately for each module, so the mismatching effects that you mention are taken care of in our simulation. Kind regards, Martin

Hi Peter, if you want to connect several module areas together to one inverter, please have a look here: There is also a link to a post where this question is answered. Hope that helps, kind regards, Martin