-
Posts
1,822 -
Joined
-
Last visited
-
Days Won
169
Everything posted by developer_mh
-
Previously existing and now missing module in database
developer_mh replied to RicardoM's topic in PV*SOL
Hi Ricardo, ok, this is strange. Usually the user id is not renewed or reset except when you install it on a new device. One quick work around for you would be to copy the module with hidden user id when you open the project file where it is contained. This would make it available for you in other projects as well. I'll ask you to send me some files via private message in order to analyse the problem. Kind regards, Martin -
Previously existing and now missing module in database
developer_mh replied to RicardoM's topic in PV*SOL
Hi Ricardo, it seems that you database user id has changed from one PV*SOL to the other. Perhaps you re-installed PV*SOL on a new device? If so, make sure that you take along your database user id from the computer where you entered the PV modules and enter it in the newly installed PV*SOL. Read more here: https://help.valentin-software.com/pvsol/2020/databases/#user-ids https://help.valentin-software.com/pvsol/2020/options/#databases Hope that helps, kind regards, Martin -
Hi Vishnu, no, right now there is no possibility to add a power price in addition to an energy price - and yes, we have it on our list Kind regards, Martin
-
Hallo Mourad, nein, leider gibt es so eine Funktion derzeit leider nicht. Wir haben das auch schon auf unserer Liste, aber in kann dazu leider noch ein Datum nennen. Viele Grüße, Martin
-
Wechselrichter-Auslegung neigt zur Unterdimensionierung?
developer_mh replied to artworkad's topic in PV*SOL
Hallo Art, sehr schöne Frage! Sorry für die späte Antwort, wir sind gerade ziemlich im Trubel wegen des anstehenden Releases von PV*SOL premium 2021 R1. Zu deiner Frage: In die automatische Verschaltung in PV*SOL fließen viele Bewertungskriterien ein. Einer davon ist der Dimensionierungsfaktor, ein anderer, der hier eine Rolle spielt, ist die Anzahl benötigter Wechselrichter. Der Dimensionierungsfaktor (installierte DC-Nennleistung der PV-Module geteilt durch AC-Nennleistung des Wechselrichters) sollte dabei über 100 % liegen, einfach aus Kostengründen. Dimensionierungsfaktoren von unter 100% machen aus wirtschaftlicher Sicht keinen Sinn. Ab Dimensionierungsfaktoren von 115 % machen sich die Verluste, die man durch die Leistungsbegrenzung des Wechselrichters hat, erst bemerkbar (aber sind da noch relativ niedrig). Mit steigendem Dimensionierungsfaktoren steigt dann ab diesem Punkt auch der energetische Verlust an. Aus wirtschaftlicher Sicht kann sich das trotzdem lohnen. Wenn man stark unterdimensioniert, kann man evtl. einen WR anschließen, der laut Datenblatt vielleicht zwei Nummern zu klein ist - dafür ist er aber deutlich guünstiger. Und wenn man dann nur sagen wir 3 % Abregelungsverluste im Jahr hat, kann die Rechnung durchaus aufgehen. Wichtig: Zum Berechnen der Abregelungsverluste unbedingt in Minutenwerten rechnen. Der zweite Faktor, der hier eine Rolle spielt, ist wie gesagt die Anzahl an Geräten. Wir bewerten eine geringe Anzahl besser als eine hohe. Für unseren Algorithmus ist es also vorteilhafter, einen STP 25000 zu nehmen, der in einem Dimensionierungsfaktor von 116 % resultiert, als zwei von den STP 15000, die dann zusammen auf einen Dimensionierungsfaktor von unter 100 % kommen. In der Übersicht über die automatischen Verschaltungen kann man sich dann die Rangliste und die einzelnen Bewertungskritierien nochmal genauer anschauen. Wenn man dort auf die kleinen (i)-Buttons neben den blauen Balken mit den Prozent-Werten klickt, sieht man die Einzelwertungen. Für den STP 250000: Für die zwei STp-15000: Viele Grüße, Martin -
Name wont change on arbitrary buildings in the pv sol report
developer_mh replied to patrik k's topic in PV*SOL
Hi Patrik, the name you have to change in 3D is the module area name, not the building name. At least once the module areas are created. Module areas are named by the name of the building at the time of their creation. So, in order to change the module area name afterwards, just go into the configuration panel and change the names of the module areas in the lower section there: Kind regards, Martin -
Dear Falah, we don't have a video right now, but thanks for the suggestion. Perhaps these help pages might help you getting started: https://3d-help.valentin-software.com/pvsol/en/#t=html%2Fen%2F3d%2FEinfuehrung_in_den_Kabelplan.htm Kind regards, Martin
-
Hi Marc, thank you for sending the project. In my case I was able to go into 3D, configure the modules, change the configuration a bit, go back, calculate the shadows and then simulate the whole system without a problem. RAM usage was moderate, also during autosave. The highest peak was around 900 MB. Could you describe in which situations the program crashes? Also, I realized that PV*SOL is using my GPU a lot during the shading calculations. Perhaps you have a dedicated GPU in your computer as well? If so, try configuring PV*SOL to use the better GPU, like so (example is for NVIDIA, but I guess for other manufacturers it is similar): Kind regards, Martin
-
Hi, thank you for sending the project. The problem here is that in winter the consumption is way too high compared to the PV production. In January for example you have a consumption of around 250 kWh, but the PV production is only around 70 kWh. This won't work. In order to be able to simulate and see how much consumption you can cover in which month, just set the check box for "Load Shedding" below the list of appliances: Then you'll be able to simulate and see the results. The loads will always be switched off when there is not enough PV power. Hope that helps, kind regards, Martin
-
Hi Marc, if you didn't receive an email with a reference number, the error was thrown in the 3D environment. But I found the error in our logs (ref nr. 0178262, just for me to remember). The problem here is really that the process is out of memory. PV*SOL is a 32bit process which means that there is a limit of around 1.3 GB of RAM. If you send me the project I could have a look if there is a possibility somewhere to save memory (by private message please). Kind regards, Martin
-
Hello, can you clarify what the problem is? Are you not able to choose a battery inverter and batteries or do you get simulation errors afterwards? If possible, send us your project (by private message here in the forum), so we can have a look. Kind regards, Martin
-
Hi Marc, PV systems in 3D of this size can cause heavy load on the computer. Did you already send us a crash report? If so, could you provide a reference number? We could then have a look into the error and see what is happening. Kind regards, Martin
-
Hi David, this is correct, the power optimizers in PV*SOL only have one MPP tracker. The SolarEdge M2640 has four. So there is no "clean" way to enter it. As a workaround you could either enter it as PV inverter with four MPP trackers, and with the DC/AC values of the PV inverter you want to connect. So that you'll have a device that combines the M2640 and the PV inverter. The other way would be to enter it as power optimizer with only one MPP tracker, and take into account that you'll lose the simulation accuracy. If you don't have difficult shading situations on the roof, you could go this way. Hope that helps, kind regards, Martin
-
Hi Himanshu, if you want to compare two PV plant designs, I would recommend the project comparison: https://help.valentin-software.com/pvsol/2020/project-comparison/ Kind regards, Martin
- 1 reply
-
- 1
-
-
Hi Ricardo, thanks for the project. These are two different module types and if you select all of them, the generator power is calculated from the total number of modules and the lower of the two module powers. This only affects the display, however, the correct generator power will be displayed during interconnection and after exiting 3D. But I will set the issue on our list as it can easily confuse. Thanks for reporting! Kind regards, Martin
-
Hi Ricardo, thank you for reporting this with such illustrative pictures, this will make it easier for us to locate the problem. Would it be possible for you to send us the project where that happens? You can send it by private message here in the forum. Thanks, and kind regards, Martin
-
Hello Niclas, in the results section there is a diagram that shows the PV yield over the complete observation period, taking into account the module degradation: Hope that helps, kidn regards, Martin
-
Down-regulation on account of the max. AC Power/cos Phi
developer_mh replied to Daniel's topic in PV*SOL
Hi Daniel, most probably the down regulation on account of the max AC power is due to the sizing factor, yes. In general, those losses increase with an increasing sizing factor. Also be sure to simulate those losses in 1min resolution. In 1h time steps this effect can't be simulated realistically. But if you want, you can send over a project so that we can have a look in detail. Kind regards, Martin -
Hi Daniel, if you are missing the values at low light conditions, you can choose the standard low light behaviour. In most of the cases we will then use the two-diodes model internally. We also have the pan file support on our list in order to make it possible to import pan files in the future, but for now I can't give a date for that. Kind regards, Martin
-
Hallo mlo, ja, die Ertragsverluste unterscheiden sich schon je nach Montage und Einbausituation. Könntest du uns die vergleichenden Projektdateien zur Verfügung stellen, dann können wir das besser nachvollziehen. Gerne als private Nachricht hier im Forum. Danke und viele Grüße, Martin
-
Hi Holm, I am glad you found out! If you need further assistance, please let us know! See also our help pages here: https://help.valentin-software.com/pvsol/en/ Best wishes, kind regards, Martin
-
Hi Paul, thank you for the schematics! Are the electrical loads connected to the grid directly, that is, after the voltage stabilizer? I see that the MPPTs are connected directly to the batteries? Is it possible with this setup, that the PV is directly covering the loads? And, last question: Do you primarily intend to analyse the grid connected case or the offgrid case? Kind regards, Martin
- 7 replies
-
- pvsol
- add to database
-
(and 1 more)
Tagged with:
-
Base de donné PV sol Solar Carport & virtual storage
developer_mh replied to Photovoltaique83's topic in PV*SOL
Hi Photovoltaique83, thank you for the input. Do you have special solar carports in mind? Can you give examples of manufacturers? The idea of virtual storage tariffs is great, we also have some providers here in Germany. We definetely have that on our list, as this topic will be increasingly important in the future. Thank you for pointing us out on the providers in France! Kind regards, Martin -
Hi Rick, there is no out-of-the-box solution for designing DC-only systems in PV*SOL right now, I am afraid. One possible solution would be to interpret the AC mains as your DC bus, set the voltage to your DC voltage (12 or 24 or 48 V or so), and interpret the PV inverters as DC/DC converters. It will work, and energetically the errors that you'll make are small. It is not the nicest solution, I know, but it will work. If you are not connected to the grid, you will have to choose a stand-alone (offgrid) system type in PV*SOL: https://help.valentin-software.com/pvsol/2020/pages/system-type-climate-and-grid/ Hope that helps, kind regards, Martin