developer_mh

HI Jimmy, yes this is possible. Please refer to this thread here: Kind regards, Martin

Hallo Andreas, danke für die Projektdatei. Die -15.766,55 € kommen folgendermaßen zustande: Man hat den Kredit in Höhe von 14.076,00 € auf dessen Restschuld man 20 Jahre lang Zinsen von 1,76 % zahlen muss. Die Kreditschuld und die Gesamtzinsen über 20 Jahre werden als Gesamtschuld betrachtet und ergeben sich zu 16.955,95 €. Das kann man nachrechnen, indem man die Kreditzinsen aller Jahre aufsummiert. Im ersten Jahr zahlt man davon 1.189,40 € ab, das entspricht dem jährlichen Cashflow ohne die Zinsen, da man die ja schon in die anfängliche Gesamtschuld mit aufgenommen hat, also 941,66 € + 247,74 € = 1.189,40 €. Es ergeben sich -15.766,55 € im kumulierten Cashflow abzüglich noch ausstehender Kredite. Hoffe, das hilft weiter. Beste Grüße, Martin

Dear Solarific, yes, in PV*SOL you can also use DC coupled battery systems. There are three kinds of coupling: AC coupling (coupling takes place on the AC side, after the PV inverter) DC intermediate circuit coupling (coupling takes place inside the PV inverter, in the DC intermediate circuit, i.e. before the DC/AC stage) DC generator coupling (coupling takes places on the DC string, before the PV inverter) See more information and grafics here: https://help.valentin-software.com/pvsol/en/calculation/battery-systems/#type-of-coupling Hope that helps, kind regards, Martin

Dear Sondre207, the percentage value that you enter and see displayed on the input dialog (bottom section of your screenshot) is the mean or average daily consumption in %. The consumption in kWh per month that you see in the upper diagram is the mean daily consumption multiplied by the number of days per month and then multiplied by the annual energy requirement. This is why February with its 28 days is lower than March with 31 days in the upper diagram whereas it appears higher in the lower diagram. Hope that helps, kind regards, Martin

Hi Jimmy, thanks for your explanation. A service for high quality drone models, ready to be used in PV*SOL, that is one big business idea! We know that there are a lot of people out there experimenting with this work flow as you did, trying to get drone models well prepared to be used in PV*SOL. And we are aware that this involves a very high amount of manual effort at the moment, and I guess there are just few planners that can afford putting all the time into it. So I there surely is a business case there! We wish you all the best for that enterprise and please let us know how it advances. In addition an idea could be to offer paid courses, on platforms like udemy or so, where you can pass the knwoledge to other people and still get financially rewarded. Kind regards, Martin

Hi Ryan, we didn't remove the own power percentage from the yield section. If the problem persists, please open up a new thread, perhaps along with a screenshot. Thanks and kind regards, Martin

Hi Jimmy, this really is astonishing! I especially like the quality of the edges of the buildings. Also the roof areas seem to be really plane and homogeneous! I guess a lot of our users would be very interested in your work flow there, and the data sources that you used. Kind regards, Martin

Hi, since PV*SOL is using the currency symbol of Windows, follow these instructions to change it in the Windows settings: https://www.isunshare.com/windows-10/customize-currency-format-on-windows-10.html Kind regards, Martin

Hallo Andreas, könntest du uns die Projektdatei zukommen lassen, dann ist es etwas leichter nachzuvollziehen. Gerne hier im Forum per privater Nachricht. Vielen Dank und beste Grüße, Martin

Hi Venco Gary, you can use tarriff zones when defining an from-grid tarriff, like so (never mind the € sign, the currency symbol is taken from the system): In the right side of the dialog, starting frm the top, you can set the number of zones to 3, then enter the prices for each zone (1.0207, 0.5968 and 0.2529), and then, in the tarriff zone table at the bottom, just highlight the cells you want to change and type in the number of the zone. I didn't know what the last two rows (daytime and average) where referring to, so I didn't include them in the example. Hope that helps, kind regards, Martin

Hi Kate, as Jimmy pointed out already, the module temperature really is the difference here. See our help pages for details: https://help.valentin-software.com/pvsol/2022/en/calculation/pv-modules/module-temperature/ As you can see, there is only 2K difference in comparison to "Mounted - Open Space". In addition you could adjust the albedo values in order to account for the higher reflectivity of the water surface in comparison to the standard value of 0.2, which is suitable e.g. for grass. But as you can see in this table here https://help.valentin-software.com/pvsol/2022/en/calculation/irradiation/ground-reflection/ the albedo is not significantly higher than 0.2, and is also strongly dependent on the inclination angle of the sun rays. So we don't adjust those values automatically, only the temperature difference at 1000 W/m², as mentioned above. Hope that helps, kind regards, Martin

Dear PV*SOL users, PV*SOL now features a fully automated PAN file import, accessible via the database dialog: https://help.valentin-software.com/pvsol/2022/en/databases/import-pan-files/ Hope that facilitates the usage of PAN files. We'd like to hear what you think of that new feature as well! Kind regards, Martin

Hallo Mohammad, sorry für die späte Antwort, wir hatten mit dem neuen Release alle Hände voll zu tun. Also mir ist nicht 100% klar, welche Art der Wirtschaftlichkeitsberechnung das Ziel sein soll, aber abgesehen davon, kann man das durchaus so machen, wie du es hier zeigst. Man könnte evtl. noch die Einspeiseabregelung auf 0% am Einspeisepunkt stellen, damit wirklich nichts mehr ins Netz eingespeist wird. Das geht vorne auf der Seite "Anlagenart, Klima und Netz" unter dem Punkt "AC-Netz". Und die Art der Wirtschaftlichkeitsberechnung evtl. auf Überschusseinspeisung umstellen, damit man für Deutschland übliche Strombezugstarife eingeben kann (wenn diese dann zur Wirtschaftlichkeitsberechnung hinzu genommen werden sollen). Viele Grüße, Martin

Hallo dw12623, die Frage nach dem passenden Wechselrichter lässt sich auf vielflältige Weise beantworten. In der Regel möchte man den kleinstmöglichen Wechselrichter, bei dem die auftretenden Abregelungsverluste noch im Rahmen sind. Was aber noch im Rahmen ist und was nicht mehr, ist eine individuelle Entscheidung und hängt letzten Endes von den Kosten der Wechselrichter und den anderen wirtschaftlichen Faktoren wie der Einspeisevergütung oder dem Eigenverbrauch und dem Bezugstarif ab. Eine Anlage ganz ohne Abregelungsverluste ist in der Regel aus wirtschaftlicher Sicht nicht erstrebenswert, wenn man davon ausgeht, dass man den nächst kleineren Wechselrichter zu einem günstigeren Preis bekommen kann. Aber im Detail muss das natürlich die Simulation und die Wirtschaftlichkeitsberechnung zeigen. Daher: Am besten ausprobieren mit verschiedenen Wechselrichtern, und in den Wirtschaftlichkeitsparametern möglichst realistische Preise eintragen. Dann sieht man ganz gut, wie sich die finanzielle Situation darstellt und kann die Varianten dann im Projektvergleich miteinander vergleichen. Die nominale DC-Leistung auf den Datenblättern beruht auf STC-Bedingungen, also 1000 W/m² und 25°C Modultemperatur. Die in den Carpetplots gezeigten Werte sind die simulierten Werte der Modulleistung zu jedem Simulationszeitschritt. Hier variieren Einstrahlung und Temperatur ja ständig. Insofern ist das nicht wirklich vergleichbar, bzw. vom Denkansatz nicht ganz der richtige Weg, vermute ich. Was der Unterschied zwischen den einzelnen Ergebnisgrößen genau ist, lässt sich aus der Energiebilanz ganz gut ablesen: Ja, tatsächlich, das ist eine kleine Unschönheit im Programm. Die Einheit W stimmt, bei den Texten wird (der Einfachheit halber) die Bezeichnung aus der Energiebilanz verwendet, bei der es sich um Energien handelt. Hoffe, das hilft erstmal weiter. Viele Grüße, Martin

Hi SolarEPC, this is correct, for on-grid systems we calculate the electricity production costs using the total PV energy yield, not taking into account the maximum feed-in power clipping at the feed-in point or own consumption. Concerning the own consumption I'd guess that this is correct, since you can use the rest of the PV energy for other purposes like feed-in. Concerning the clipping at the feed-in point, I'd say you are right, since the clipped energy is really "wasted" and can't be used elsewhere. I'll discuss that with my colleagues and put it on our list. Thanks for the feedback, kind regards, Martin

Hallo Mohammad, der Eigenverbrauchanteil ist ein Ergebnis der Simulation, er lässt sich also nicht vorher einstellen. Hier vielleicht noch ein Link zu einer ähnlichen Frage: Auch die Stromgestehungskosten ergeben sich aus den eingestellten Werten und der Simulation. Zu beachten sind hierbei die Installationskosten sowie die laufenden Kosten, die man auf der Wirtschaftlichkeitsseite einstellen kann, sowie die tatsächlich genutzte PV-Energie. Viele Grüße, Martin

Hi Solarific, a schedule based battery management is not available right now in PV*SOL, I am afraid. But we have it on the list. Kind regards, Martin

Hi k kent, it is only running on Windows. But if you want to run it on Mac, you can use Parallels [https://www.parallels.com/], VMWare, VirtualBox [https://www.virtualbox.org/] (or any other virtual machine that runs on Mac). Same applies for Linux. Best regards, Martin

Hallo Hannes, klar, das geht. Einfach beim Anlegen eines neuen 3D-Projekts den Kartenimport wählen und dann die Option "Von Festplatte laden" wählen. Dann kann ein Grundriss oder ein beliebiges anderes Bild geladen werden (muss im Format png, jpg, bmp vorliegen): Dann muss man noch den korrekten Maßstab ermitteln. Durch Klick auf das kleine Zahnrad gelangt man in den Maßstabsdialog, in dem man die blaue Linie mit ihren Endpunkten möglichst auf eine Bemaßungslinie zieht, deren Maße man kennt. Diese gibt man dann unten in das Feld ein: Dann alles bestätigen, und es wird der Grundriss in die 3D Umgebung geladen. Dort kann man dann mit dem Polygon-Tool den Grundriss nachzeichnen und anschließend ein 3D-Gebäude daraus extrudieren: Ich hoffe, das hilft weiter. Viele Grüße, Martin

Hi Jimmy, for your question I had to ask a colleague and this is what he replied: I guess this answers both of your questions and perhaps sheds some light on the algorithms behind it. Kind regards, Martin

Hallo Lukas, danke für den Hinweis, ich werde das weiterleiten an unser Datenbank-Team. Viele Grüße, Martin

Hallo masp, könntest du mir so eine Datei zukommen lassen? Gerne hier im Forum als private Nachricht. Danke und viele Grüße, Martin

Hi Patrice, the levels or zones in the tarriffs in PV*SOL can't be entered in kWh/kWp (or kWh/kWc in France), hence it would be necessary to enter the total kWh that these zones would refer to for your current PV system. For example, if your PV system has 100 kWp (or kWc in France), you would enter the following: So, for the first 1100 kWh of each of your installed kWp (kWc), you would get 0.098 €, and after that it is 0.04 €. If your PV system has 250 kWp (kWc), you would have to enter 1100 * 250 = 275000 kWh: Hope that helps, and I also hope that I did get your question right. Kind regards, Martin

Hi Jimmy, this function basically does what the description says. It reduces the number of points of the 3D objects in order to make the overall handling and especially the shading calculation more efficient. It is essentially an algorithm that detects similar triangles and melts them together. In this manner, the number of points is reduced. But since this reduction can lead to inaccuracies in the resulting planes, a warning is given that the user has to check carefully the shading results. Hope that helps, kind regards, Martin

Hi Thomas, in PV*SOL it is not possible to place modules or a module mounting on curved surfaces. You'll have to split the surface into small elements with even surfaces, large enough to place PV modules onto it. Also see these posts for reference: Kind regards, Martin