developer_mh

Hi Jonas, perhaps you find the workaround for this problem here in this thread: Kind regards, Martin

Hallo Sebastian, ja, auch das geht. Einfach die Modulflächen gemeinsam verschalten und dann die Option Polystring wählen. Damit kann man alle erdenklichen Verschaltungen realisieren. Viel Erfolg und beste Grüße, Martin

Dear Waqar Ahmad, the horizon line is representing the border between the visible sky and the surrounding (hills, mountains, far buildings etc), from the point of view of the PV array. Here you can find more information: https://help.valentin-software.com/pvsol/2020/calculation/irradiation/horizontal-shading/ https://help.valentin-software.com/pvsol/2020/pages/pv-modules/shading/ Hope that helps, kind regards, Martin

Dear Waqar Ahmad, in order to see the 25 years of annual yield, you'll have to change the time range of the assessment period to 25 years. This can be done in the economy settings: Then simulate, and find the diagram of the annual yield here: Hope that helps, kind regards, Martin ps: Please try to find a suitable description for your threads, like in this case "Diagram for annual PV yield over 25 years" or so. Then it will be easier to find also for other forum users.

Hi Anton, yes, the power figures must be taken from the datasheet of the MultiPlus-II and then entered into PV*SOL either for the PV inverter or the battery inverter. You'll have these two devices in PV*SOL that represent the one MultiPlus-II device. Kind regards, Martin

Hallo Michael, bei der Berechnung der Abschattung in 3D, also wenn man aus der 3D-Visualisierung zurück zu PV*SOL kehrt, ist eine gute GPU-Leistung vorteilhaft. Für die eigentliche Ertragssimulation, also vor der Seite "Ergebnisse" ist eine gute single core (auch "single thread") Performance vorteilhaft. Diese ist auch generell für die Nutzung von PV*SOL hilfreich. Beste Grüße, Martin

Dear Jan, one way would be to remove the electrical appliances from the project, that is, set the project type to "Grid connected PV system". But this is perhaps not what you want. The other option would be to set the from-grid price to 0 €/kWh, then the electricity savings don't appear in the cash flow. Hope that helps, kind regards, Martin

Dear Sarah, these kind of systems are currently not supported in PV*SOL, I am afraid. We have this topic already on our list, but I can't tell a date for the release right now. Kind regards, Martin

Dear Waqar, you can define the height of the mounting structure here: This dialog pops up when you create a new module mounting system. Hope that helps, kind regards, Martin

Hi Anton, the Victron MulitPlus II approach is somewhat different to our ongrid and offgrid system types. I'd interpret it as offgrid for the PV (as it does not feed into the grid), but ongrid for the loads (as loads are covered by grid energy). In case of grid outage, it would clearly be a DC coupled battery offgrid system: I think the most suitable way to model this in PV*SOL would be an offgrid system with diesel backup generator, and you interpret the generator energy as from grid energy. In offgrid systems in PV*SOL you can also define load shedding, which might be useful for this kind of application. Then, you define a PV inverter with the MPP tracker properties of the MPPT solar charge controller. The DC/AC efficiency would be your DC/DC efficiency of the solar charger. And then you need an offgrid battery inverter with the corresponding properties of the MultiPlus-II. This should give you results that are as close as possible with PV*SOL at the moment. Let me know if this helps. If you need any further assistance, please don't hesitate to ask. Kind regards, Martin

Hi Anton, do you have a schematic drawing of your system? Perhaps we can find a system type that comes close to your application. But a pure DC coupled offgrid system is not possible right now in PV*SOL, I am afraid. Kind regards, Martin

Hi Frido, yes, I do exactly understand what your points are, thank you for letting us know. We have these features requests and tweaks on our list, but right now I can't say when they could be released. For your first and initial problem, there might be a viable work-around (which I used for my screenshot as well). If you use module mounting systems instead of module coverage it should work as you expected. Module coverage relies on a fixed grid, which is why the outcome is like in your image, buiding B1. When covering the roof, the strict grid is followd, and if there is an obstacle or barred area, the module will not be placed. For a lot of applications, this might be the wanted behaviour. When using module mountings, you don't have this fixed grid, but each row is placed independently, so it results in a layout like in my screenshot. Give it a try and let me know if this does the trick for you. Kind regards, Martin

Hi Rasmus, sorry for the late reply. A simulation with another start or end date is not possible I am afraid. But concerning your concrete request about the SOC in offgrid systems: When the simulation starts, the batteries are set with an initial SOC value. In the case of offgrid plants, this is pre-calculated as an expected average SOC from the backup generator SOC thresholds. Even if the backup-generator is not used in the system, ie if you have chosen a system without backup generator, these thresholds are used. This was done for historical reason (in terms of software development), and we plan to change it in the future, but right now it would help you to manipulate the starting SOC. Just select the system type with diesel generator, set the SOC control thresholds to 80 and 90 respectively, and then change the project type back again. If you run the simulation now, the starting SOC will be between 80 and 90 %. No guarantee that this will work in the future but then we will have some other sort of editable starting value. For on grid battery systems the starting SOC value is fixed at 80%. For electric vehicles the starting SOC value is fixed at 100%. Hope that helps, kind regards, Martin

Hallo Marco, wir haben leider aus Zeitgründen noch nicht im Detail ergründen können, warum der Import dieser konkreten obj-Datei dieses Verhalten hervorgerufen hat. Es hatte sich dann auch insofern geklärt, als dass der Import im dae/3ds-Format geklappt hat. Es ist uns schon länger leidlich bewusst, dass die Welt der 3D-Formate sehr komplex ist, und auch innerhalb eines Formats wie z.B. obj, immense Unterschiede in der Interpretation durch die verschiedenen Tools liegen. Gute Erfahrungen haben wir mit obj-Modellen gemacht, die aus Blender kamen, aber hatten auch schon oft Probleme mit obj aus anderen Quellen. Daher bietet es sich auch immer an, die verschiedenen Formate auszuprobieren, die die Tools als Export anbieten. Viele Grüße, Martin

Hi Emmanuel, could you give more detail about the problem? Or provide a screenshot? Kind regards, Martin

Hi Frido, at the moment you have the possibilty to achieve thermal gaps with barred areas, which you can define in their width (first image), and then multiply them (second image). Then you can place module mounting structures on the whole roof (or open area), and the barred areas are automatically left as gaps. Note that the first segment on the left might need a little adjustment depending on your geometry. In the future, we want to offer a more comfortable way to define these gaps, but I can't give a date right now. Hope that helps in the meantime, kind regards, Martin

This is excellent, Jordn! Thank you for sharing this. Impressive! Really a nice idea to share those projects. Some time ago there was another project from UK that was shared here in the forum, let me see if I can find it. Here it is. I like it because there is also a picture of the real PV system: Kind regards, Martin

Dear Jordn, the sun position graph is visible in the horizon editor. In 3D projects this is here: In 2D projects it can be found here: The lines shown for every month refer to the 21st of each month, so that the real solstice can be seen. Kind regards, Martin

Hallo Frido, danke für den Fehlerbericht. Das ist kein Problem, das uns bekannt ist. Insofern würden wir uns freuen, wenn du uns die originale obj und die von dir erstellte pvprj zukommen lassen könntest. Gerne per private message hier im Forum. Danke und viele Grüße, Martin

Hallo Magge, die Testversionen haben den vollen Funktionsumfang, daran kann es also nicht liegen. Könntest du mal einen Screenshot schicken von dem Haus, dessen Dach du einzustellen versuchst? Am besten mit dem Bearbeiten-Dialog im Vordergrund, der die Einstellungen zeigt, die dann bei dir nicht klappen. Dank und Grüße, Martin

Hi Frido, could you send us the project file that you are having these problems with? You can send it via private message here in the forum. Thanks and kind regards, Martin

Dear Vikrant, in those cases please contact our sales team at sales@valentin-software.com, with your customer number and your serial number. They will be able to help you out. Kind regards, Martin

Dear Richard, I must admit that I have not seen an inverter with 162 DC inlets before... and yes, the maximum number of inlets in PV*SOL is 100 at the moment. But in PV*SOL you can connect more than 18 strings to the inverter anyway, even if the number of DC inlets is smaller. The consequence is that in the cabling page, a connection box (GCB) is used to connect the strings to the MPP tracker. But we will increase th elimit of that DC inlet field in the future, thanks for the feedback. Kind regards, Martin

Dear Vishnu, please do not apologize for aksing these questions. You can be sure that if you have the question there will surely be others that have the question as well. 1) Unless the manufacturer explicitly forbids the usage of modules with higher power, you don't risk the loss of warranty (but I am not a lawyer) or damage of the micro inverter. As you said, in usual conditions a 340 Wp module is not delivering 340 W. What you risk if you connect a module with higher power, current or voltage to an inverter is the clipping. The inverter just cuts anything that is over these threshold values, and you lose a bit energy. How much you lose can be verified in the results section, under "Energy balance". 2) Yes, clipping occurs for current, voltage (min and max) and power limitations. And yes, you are right, most of the employees of Valentin are Berlin based. Thank you for your wishes, same to you! Kind regards, Martin

Dear Lenka, in PV*SOL we don't display the DST in our results. That is, when you see a time stamp saying August 13 16:00, it means that your watch would show 17:00 if you are in a region with DST (like Europe for example). That is what we do, correct. We decided not to move data in the diagram. The reason is that you would create a data gap of one hour when the time switches from winter to summer, and you would have an overlap of data in autumn, when you switch back. And additionaly the DST rules can get very complex around the globe, so we decided to provide standard winter time. But yes, if you read the diagrams, the time stamps in summer must be moved one hour forward. Kind regads, Martin