-
Posts
1,790 -
Joined
-
Last visited
-
Days Won
167
Everything posted by developer_mh
-
Hallo N_G, hast du für die zehn Jahre je eine Datei? Wenn ja, musst du sicherstellen, dass sich die Bezeichner in der ersten Header-Zeile unterscheiden. Sonst denkt PV*SOL, dass die Datei schon vorhanden ist. Beste Grüße, Martin
-
Hi David, PV*SOL takes the cycles from the database entry of the respective battery system, more precisely from the battery that is used in the battery system: The deeper the depth of discharge, the smaller the cycle number that the battery system can run. In the simulation, the current DoD of the battery is taken in order to determine the cycle load for the current time step. Hope that helps, kind regards, Martin
- 1 reply
-
- 2
-
Dear xueting, this looks good so far. So as a next step I would recommend to look at the irradiance values before and after the simulation. Best option here would be the diagram editor where you can select the time series you want to analyze. You can select the "Irradiance onto horizontal plane" and the "Irradiance onto tilted plane" and see how it looks like. You can right click and copy the values to the clipboard, and compare them to the values that you imported. Just to be sure, also have a look at the elevation of the sun. Its curve must be in sync with the irradiance values, that is, sunrise and sunset must not be shifted. Next check would be the PV module data that you entered. Especially the low light behaviour might be a reason for an unusually good performance. If you wish, you can also send your irradiance data as well as the project file so that I can have a quick look. you can send the files here in the forum via private message. Kind regards, Martin
-
Batteriesysteme in Datenbank mit falscher Kapazität hinterlegt
developer_mh replied to Ralf's topic in PV*SOL
Hallo Ralf, ja, ich verstehe das Problem. Im Datenblatt steht bei der Anmerkung zur nutzbaren Kapazität Folgendes: Da wurde scheinbar der Begriff nutzbare Kapazität für Marketingzwecke etwas gedehnt. 100% DoD (depth of discharge) ist eben genau nicht die nutzbare Kapazität, sondern die Nennkapazität. Eingegeben werden die Systeme ja in der Regel vom Hersteller. Ich leite das mal an unser Datenbank-Team weiter, dass die nochmal bei GoodWe nachhorchen. In der Zwischenzeit kannst du das entsprechende Batterie-System aber auch einfach kopieren und für den minimalen SOC eure 7% eingeben. Den Wunsch nach widerspruchsfreien Daten hegen wir in der Tat auch, ziemlich intensiv sogar. Gerade in Bezug auf leider oft eher marketingorientierte Datenblätter bleibt dieser Wunsch jedoch des Öfteren unbefriedigt. Beste Grüße, Martin -
Falsche Einheitsangaben bei WärmepumpeImport (GeoTSOL)
developer_mh replied to BobWolf's topic in PV*SOL
Hallo BobWolf, beim Ex- und beim Import der Daten ist da scheinbar ein Fehler mit dem Dezimal-Trennzeichen aufgetreten. Am besten vor dem Import in PV*SOL mal die exportierte Datei mit einem Texteditor öffnen und schauen, welches Dezimaltrennzeichen dort verwendet wird (das ist abhängig von den Systemeinstellungen). Dieses Dezimaltrennzeichen ist dann beim Import der Daten in PV*SOL anzugeben. Beste Grüße, Martin -
Hallo aqualx, ein separater Strombezugstarif ist nur möglich bei der Verwendung des thermischen Systems. Beste Grüße, Martin
- 1 reply
-
- 1
-
Batteriesysteme in Datenbank mit falscher Kapazität hinterlegt
developer_mh replied to Ralf's topic in PV*SOL
Hallo Ralf, bei den Batterie-Systemen muss man unterscheiden zwischen der Nennkapazität und der nutzbaren Kapazität. In diesem Fall hat z.B. das System mit der BYD HVS 10.2 eine Nennkapazität von 25 Ah auf 409,6 V = 10,2 kWh. Der minimale Ladezustand liegt bei 20% (etwas hoch, aber durchaus realistisch), der maximale bei 100% (meiner Meinung nach eher zu hoch, da Batterien nur sehr selten bei diesen hohen Füllständen betrieben werden sollten). Daher sind nur 80% der Nennkapazität auch wirklich nutzbar. 80% von 10,2 kWh macht 8,2 kWh. Kein Grund zur Sorge also. Beste Grüße, Martin -
Hallo Semjon, am besten erstellt man Aufständerungen nicht nur mit einem Element, das man dann vervielfachen muss, sondern gleich mit der gewünschten Anzahl an Elementen. Dazu kann man entweder einen Rahmen aufziehen, der dann mit der Aufständerung gefüllt wird, oder man kann die gesamte Fläche maximal belegen lassen: Beste Grüße, Martin
-
Hallo in die Runde, wir haben SMA bereits mehrfach kontaktiert, sie wissen also Bescheid. Wir hoffen ebenfalls, dass sie die fehlenden Modelle zeitnah eintragen. Viele Grüße, Martin
-
Hi Codrin, no, you can't define a charge/discharge schedule for the battery systems right now, I am afraid. You can set the SOC limits however, which already gives plenty of possibilities to modify the charging behaviour: https://help.valentin-software.com/pvsol/en/pages/battery-system/charging-strategy/ The feature request to be able to define a schedule as well is already on our list, but it is not planned yet, I am afraid. Kind regards, Martin
-
Hallo Hannes, inwiefern funktioniert das nicht mehr? Ich habe es eben nochmal probiert und es scheint mir so zu funktionieren wie immer.. Wenn alle Module bereits in Strings verschaltet sind, und man weist z.B. die Module von MPP-Tracker 2 dem MPP-Tracker 1 zu, dann werden die bisher an MPP-Tracker 1 verschalteten Module entfernt. Ist es das, was du meinst? Diese "freien" Module können dann aber leicht über einen Rechtsklick wieder einem Tracker oder einem Strings zugewiesen werden. Dies kann man auch automatisch erledigen lassen, in den Optionen gibt es hier eine entsprechende Einstellung: Wenn das aktiviert ist, hat man beim Arbeiten vielleicht eher das Gefühl von einem echten Modul-Tausch, da die frei werdenden Module wieder direkt zugewiesen werden. Beste Grüße, Martin
-
Hi CodrinSomesan, yes, you can simulate PV systems with electrical appliances and battery systems in PV*SOL. We have around 3000 real battery systems in our database which you can try out. Additionally you can define your own battery system. In order to see the battery system page, you'll have to activate a corresponding system type: Kind regards, Martin
-
Hi all, here is my reply from the other thread:
-
Dear SPsolar, yes, we have news on this. We seem to have found a fix for all those issues of high shading values, which will be released with the upcoming PV*SOL premium 2022 R5. Right now we are in the testing phase. So it would be more than helpful if you (and other users reading this) could send us the models that are causing the high shading values. The release is planned for this month already, so if you could send the files in the next days that would be really great. You can send them either here in the forum as rivate message, or to hotline@valentin-software.com, asking them to forward the files to me (Martin). Thanks a lot for your patience and help, kind regards, Martin
-
Dear xueting, simulation comparisons are really interesting, I am happy to see that you want to test PV*SOL simulation values against measurement. When looking at the details, there can be a lot of reasons why the results differ. In order to answer your question we would have to know a lot more about the two sides of the experiment: First, the measurement: How did you measure the global irradiance? Which sensor did you use? In what environment was the sensor installed? In which intervals was it cleaned? Did you measure global horizontal irradiance or tilted, i.e. in the PV module plane? How many modules do you have on your test stand? How are they connected? Do you measure the electricity on the DC or the AC side? Second, the simulation side: How did you determine the input parameters for the simulation? For example, the module data: Did you use data from our database or do you have flasher data that you were able to enter? Which models did you choose to calculate the irradiance on the tilted plane? There are really a lot of factors that influence the outcome of such a comparison. Without a lot more details on the measurement setup and the PV*SOL project file, however, we can't answer your question in a satisfying manner. Hope that helps, kind regars, Martin
-
Hallo Anja, deine Vermutung war schon korrekt, bei dachflächenübergreifenden Verschaltungen lässt sich der Kabelplan nicht manuell editieren. Daher lässt sich in diesem Fall auch keine Kabel-Durchführung setzen. Viele Grüße, Martin
-
Hi Anna, in projects with a lot of module areas, a lot of MPP trackers or a lot of inverters, we need to cut some of the more detailed results due to memory limitations and disk space. I'd guess that the project you are analysing has a lot of module areas? You can set the limit a bit higher, though, at your own risk Close PV*SOL, then open the PVSOL.ini file in a text editor. You can find it here: C:\Users\USERNAME\Documents\Valentin EnergieSoftware\PVSOL premium 2022\PVSOL.ini Locate the attribute MaxNumberOfModuleAreasForResults and change the value to your liking. You can also play around with MaxNumberOfInvertersForResults and MaxNumberOfMppsForResults. Save the file and start PV*SOL again. Then force a new simulation under Options -> Force simulation. Then the module area results should show up. Kind regards, Martin
-
Dimensioning fields for buildings/windows etc malfunction
developer_mh replied to Lukas Bernhard's topic in PV*SOL
Hi Lukas, to me this looks like an issue with your decimal separator (comma vs point). Check your settings in the regional settings of Windows, perhaps you have a point there, but you enter the numbers with a comma? Kind regards, Martin -
Hi Tomasz, could you provide the project file as private message, please? Thanks and kind regards, Martin
-
Hallo Anja, danke für das Melden des Fehlers, und auch danke fürs Senden des Absturz-Berichts. Es scheint in diesem Fall an OneDrive zu liegen, in der Log-File steht "Der Clouddateianbieter wird nicht ausgeführt." Beste Grüße, Martin
-
Hallo babylon05, das ist ein sehr interessanter Fehlerfall für uns. Könntest du mir das Projekt, bei dem der Fehler "Visual3D.dll" kommt, bitte hier im Forum als private Nachricht schicken? Die Log-Files bräuchten wir auch, die findest du unter C:\ProgramData\Valentin EnergieSoftware\log die mit pvsolpremium und Wow6432 im Namen sind interessant für uns. Vielen Dank und beste Grüße, Martin
-
Fehlermeldung Folgende Module sind nicht in der Datenbank vorhanden
developer_mh replied to bene-solar's topic in PV*SOL
Hallo bene-solar, vielen Dank für das Projekt. Es stammt scheinbar aus der Zeit vor der Einführung der Online-Datenbanken, die erste gelistete Programmversion ist die 2019 R14. Daher können die seinerzeit selbst angelegten Module nicht in der Datenbank gefunden werden. Eine Lösung wäre, diese Module in der neuen Datenbank (verfügbar seit PV*SOL premium 2020 R1) erneut einzugeben und die jetzt im Projekt existerenden dann damit zu ersetzen. Beste Grüße, Martin -
Hallo D.Hajrizi, welchen Verbrauch man wählt, hängt ganz davon ab, wie die Begebenheiten vor Ort sind. Wenn der Anlagenbetreiber, also euer Betrieb, für den gesamten Verbrauch des Werkes zu zahlen hat (was der Normalfall ist), dann ist auch dieser gesamte Verbrauch anzugeben. Wenn es aber zum Beispiel ein Subunternehmen gibt, das die PV-Anlage auf der Halle betreibt und nur für die Stromkonsten aufkommen muss, die in der Halle entstehen, müsste man nur diesen Verbrauch angeben. Wichtig ist, dass es bei PV-Anlage und Verbrauch nicht um einen lokalen Zusammenhang geht, sondern um einen wirtschaftlichen. Solange Verbrauch und Erzeugung in einem räumlichen Zusammenhang stehen, wie es bei einem solchen Werk ja immer der Fall ist, kann man von Eigenverbrauch im Sinne vom EEG ausgehen. Beste Grüße, Martin
-
Fehlermeldung Folgende Module sind nicht in der Datenbank vorhanden
developer_mh replied to bene-solar's topic in PV*SOL
Hallo bene-solar, könntest du mir das Projekt zukommen lassen? Gerne hier im Forum als private Nachricht. Danke und beste Grüße, Martin