Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


developer_mh last won the day on November 7

developer_mh had the most liked content!

Community Reputation

29 Excellent


About developer_mh

  • Rank

Profile Information

  • Gender

Recent Profile Visitors

1,667 profile views
  1. Hi Jack, thank you for sending the project files. I can confirm that I see the same behaviour. There seems to be a bug when using module mounting systems with an inclination of 0,01° and module numbers of above 4 or 5. I think the root of the problem is that the module mounting systems are not used in the way we intended. If you want to place modules parallel to roof, consider to place them directly on the roof using the "module coverage" mode instead of using mounting systems. See more here: https://3d-help.valentin-software.com/pvsol/en/#t=html%2Fen%2F3d%2FEinfuehrung_in_die_Modulbelegung.htm There the bug doesn't effect you, and you can also work faster and more flexible. I configured one of the projects that you sent me in this way to demonstrate what I mean. I will send it to you by private message. I hope this helps, kind regards, Martin
  2. Hallo Ralf, hallo GeromeK, ja, das stimmt natürlich, über die Grenze hinweg lassen sich dann keine Module legen. Ein entsprechendes Dach fehlt in den Vorlagen, auch das ist richtig. Die Alternative wäre, wie bereits erwähnt, ein Satteldach mit den Sperrflächen zu versehen. Zur Präsentation beim Kunden könnte man, wenn die Sperrflächen optisch nicht gefallen, z.B. auf Photo Plan zurückgreifen. Die Variante mit dem 2D-Dach scheint mir in diesem Fall keine geeignete Alternative zu sein, da hier gegenüber der Variante mit dem Satteldach und den Sperrflächen ja nichts gewonnen ist. Beste Grüße, Martin
  3. Hallo Ralf, Krüppelwalm-Dächer werden bei uns immer in zwei Segmente unterteilt, da die entstehenden Dachflächen nicht zwangsweise den gleichen Neigungswinkel haben. Hier z.B.: Man kann aber natürlich trotzdem beide Teil-Dachflächen belegen und dann gemeinsam elektrisch verschalten, indem man im Reiter "Modulverschaltung" auf "Alle unverschalteten Modulflächen verschalten" klickt. Dann mit gehaltener Strg-Taste beide Modulflächen selektieren, auf "Modulflächen gemeinsam verschalten" und dann wie gewohnt verschalten: Ich hoffe, das hilft weiter. Beste Grüße, Martin
  4. Hi Sebastian, sorry for the late answer, I think we overlooked it and forgot to reply. The data that is displayed in the carpet plots is identical to the data in the time series. So you just have to select the according time series, eg. "Irradiance onto horizontal plane", choose the full year as time period and then right click and export it to Excel. Hope that helps, kind regards, Martin
  5. Hi Alisson, it seems that the picture that you attached is not there. Could you try and upload it again? Kind regards, Martin
  6. Hi Jack, thank you for reporting this strange behaviour. Could you send us a project file so that we can reproduce the issue. You can also send it by private message here in the forum, so that it doesn't become public. Kind regards, Martin
  7. Dear Bulent, thank you for your question. In PV*SOL, we use climate data from the well-known climate data specialist Meteonorm, see here: https://help.valentin-software.com/pvsol/calculation/irradiation/climate-data/ PVsyst also uses Meteonorm, so in terms of irradiation data there shouldn't be any difference between PV*SOL and PVsyst. Do you have an example project where we can see PVsyst and PV*SOL energy yields side by side? Often the differences in the energy yield come from the models that are used to calculate the irradiance on the tilted plane of the PV modules. These models can be modified in the program options under Options -> Program Options -> Project Options -> Simulation: Regarding values from SolarGIS: Yes, it is not unusual that climate data values can vary within +- 15 % between the sources. SolarGIS uses mainly satellite data, if I remember correctly. Meteonorm uses mainly ground measurement stations in combination with satellite data. And then there is PVGIS which also uses satellite data and whose values differ both from SolarGIS and from Meteonorm. See some details about the meteorological approaches here: SolarGIS: https://solargis.com/docs/methodology/solar-radiation-modeling Meteonorm: https://meteonorm.com/assets/downloads/mn73_theory.pdf PVGIS: https://re.jrc.ec.europa.eu/pvg_static/pvgis5.pdf As you will soon realize, there is no true or false for climate data. Nor is there any "higher values are better". It depends on what you want to achieve. If you want to achieve a higher simulated energy yield than your competitor, yes, you might be willing to choose the data source with the highest irradiation for a given place. But what happens if this simulated energy yield is too high? Won't the customer be dissappointed? We think that on the ling run, it will shed a negative light on the project planners and users of our software (and the whole industry), which is why we always try to provide simulations that are conservative, but sitll realistic. The climate data of Meteonorm do fit nicely in this "conservative" concept, where the yield that we simulate is nearly always topped in reality. But of course, you are free to import any other climate data into our software and simulate with that. A guide how to import climate data from other sources can be found here: https://help.valentin-software.com/pvsol/pages/system-type-climate-and-grid/meteosyn/#options Hope that helps, kind regards, Martin
  8. Here is the excel sheet, you can just paste your monthly values into the green fields and copy the blue fields to the clipboard PVSOL Modify Monthly Consumption Percentage Before Import.xlsx
  9. Hi Tim, you are right, the import of the 12 monthly values in the dialog you posted in your first post are not accurate. This is a bug we know of quite some time, but this section of our software is/was a remainder from older times This is one of the reasons why we refurbished these old components now. In the next major release (which is planned for early 2020), an update of the consumption dialogs is included. In the meantime, if you work with net metering you can enter the monthly consumption values directly here: Or, if you are willing to modify the monthly consumption before importing them, you can do the following: Import the monthly energy values in kWh and calculate the monthly percentage (first two columns) Calculate the monthly modification factor with (days of month) / (365/12) Calculate the converted percentage with (real percentage) / (modification factor) then you can select the last column, copy it to the clipboard and paste it into the dialog that you showed Then click ok and enter the yearly energy consumption here Then you'll get the monthly energy consumption into PV*SOL as desired: Hope that helps, and sorry for the circumstances. Kind regards, Martin
  10. Hi Glenn, in addition to my colleague's comment I'd like to add that in our current PV planning software PV*SOL premium 2019 you'll find all the features that were available in the SMA Offgrid Configurator as well, and lots more. See here for a features overview: https://pvsol.software/en/features-pricing or https://www.valentin-software.com/en/products/photovoltaics/57/pvsol-premium You can also test these applications for free for 30 days. Kind regards, Martin
  11. Hallo Ralf, ja, diese Erweiterung steht bei uns auf dem Zettel. Terminlich können wir dazu zwar noch nichts sagen, aber wir arbeiten dran. Beste Grüße, Martin
  12. Hallo OD111, eine Möglichkeit wäre, eine Art Projekt-Vorlage zu machen und diese bei jedem neuen Projekt zu laden. Dazu einfach das gewünschte Lastprofil auswählen und das Projekt unter einem aussagekräftigen Namen speichern, z.B. "Projektvorlage - Verbrauchsprofil Einfamilenhaus Mitteleuropa.pvprj". Das kannst du in Zukunft dann zu Beginn eines neuen Projektes laden, dann direkt unter einem neuen Namen speichern ("Speichern unter" -> aktueller Projektname) und dann weiterarbeiten. Beste Grüße, Martin
  13. 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
  14. 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
  15. 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
  • Create New...