developer_mh

Hi Marta, what do you mean by "Trim Map"? I just tried it again here, I chose the climate location Portugal - Ponta Delgada, then I open the 3D environment, choose "Map Section", then click on the Image "New Map Section, Click here", then I see this: This seems dark, but is just ocean. It is dark blue If you zoom out just a little (not totally), you see that the island is just nearby: Perhaps this is what confused you. You can drag the map with your mouse, you can zoom with the mouse wheel. Just select the location you want, zoom in so that neither the height nor the width label are red, and hit "OK". Good luck, kind regards, Martin

Hi Vicente, could you send us the 3D model (the obj file), so that we can have a look? Thanks, Martin

Hi Marta, regarding the first question: Perhaps your internet connection was not up when you first searched. Try to search again for "ponta delgada Açores", and it should show the following: Sometimes, if the internet connection hangs, nothing is shown. So try to zoom in and zoom out and then it should be fine. Regarding the second point: The "OK" button is disabled if the selected map area is too large for PV*SOL 3D environment. It can handle 800 m in East-West (Width) and 800m in North-South (Height) direction. If either dimensions is exceeded, the corresponding field is labelled in red and the OK button is disabled. Hope that helps, kidn regards, Martin

Hallo Raphael, Meteonorm 7.3 wird spätestens in der Version 2020 R1 kommen, also im Herbst diesen Jahres. Beste Grüße, Martin

Hi James, you can send me files here by private message, thank you. Kind regards, Martin

Hi Vicente, if you use imported 3D models like the one you have, shadings from "verges" (or parapets, or attics or how they are called) can lead to wrong results. A solution would be to remove the verge/parapet/attic from your model, import it afterwards in PV*SOL and then place a verge there. Like so: Then the shading calculations should be fine. Hope that helps, kind regards, Martin

Hi James, yes, we had this problem again with the climate data. And before I begin, I'd like to repeat our apology for the inconvenience caused. It is difficult to explain why this happened without explaining in detail our code structure, employee situation and testing environment. But you as a user have a right to know, so I'll try it. As you know we already had this bug one year ago in our 2018 version. That time we already developed a new version of PV*SOL (2019 R1) where we refactored (restructured, redesigned) a lot of code. When software grows over time, developers have to do this regularly in order to keep the code base manageable and extensible. As a consequence we had two versions (we speak of repositories, with several branches each) of the code base, the old one (2018 line) and the new one (2019 line). The bug we had with the Meteonorm data was fixed in the 2018 branch, but the employee who introduced and fixed the bug in the 2018 repository forgot to fix it in the 2019 repository as well. Before we published this new version he left our company (a bit spontaneously) and although we had a lot of handover meetings before he left, we oversaw this one line in the installation script that fetched the old MN data into our installation. There is a lot more to it but I won't go into details. All I can say is that we are really sorry that this happened again and we are aware of the message boxes are annoying our users once more. Thanks and kind regards, Martin

Hi Tim, thank you for your feedback. I will forward this question to our database team and see what they say. Kind regards, Martin

Hi Kamal, right now we don't have a distinct simulation model for half cell modules. But as we recognize that these modules are getting more and more popular, we do have this feature already on our list and hope to publish it soon. In the meanwhile you can just enter your own module data as follows: With these data you can simulate the module. The only thing that will not be 100% correct is the behaviour in partly shaded conditions, so simulate with care Kind regards, Martin

Hi Kamal, thank you for your question. In general the specific yield is not influenced by the consumption or the battery system, as long as it is AC coupled. That means that electric appliances and the battery system etc are connected on the AC side of the PV inverter. This is the case for most of the battery systems. But there are systems that are coupled on the DC side of the PV inverter, we call that DC generator or DC intermediate coupling. Refer to these explanations here: https://help.valentin-software.com/pvsol/2019/calculation/battery-systems/#type-of-coupling In the case of DC couplig the battery system and the consumers influence the AC output of the PV inverter, and so they influence the specific yield. On the one hand this is obvious, on the other hand it might seem a bit confusing, as you pointed out correctly. We are aware of this and we think of making it more clear in the results where the differences in yield come from. Hope that helps in the meanwhile, kind regards, Martin

Hi aapn77, since you posted this request in the PV*SOL forum, let me answer first from the PV*SOL perspective. I'll cover the points you mention in your question. You can import your solmetric suneye directly You can auto-fill any roof design, either in 2D design mode or in 3D You can have arbritrarily shaped "no-module-zones" You have regular updates of the software and the database, so you are always up to date You'll get (validated!) radiation data from all over the world You can also import Sketchup models in PV*SOL you you prefer to make your 3D models in Sketchup You get a very detailed and nice-looking report for your customers You get all the plans and drawings and nice screenshots on top You really shouldn't do all this work in an Excel sheet Let me put it like this: If you are a PV enthusiast or hobbyist, there is nothing wrong with cobbling your own calculation tool together. But if you are a professional this effort is just not worth it. The costs for PV*SOL will be saved within three to 10 PV projects that you plan, I would guess, depending on where you work and what size your projects are. Not to mention that you will have to prove to your customers that you did a good calculation and that there are no errors. We develop PV*SOL for about 25 years now, and have invested a lot in the validation of our algorithms, climate data, PV module and inverter databases and so on. No single person can provide that, it wouldn't make sense. My suggestion would be to just test PV*SOL 30 days at no cost and then evaluate if it fits your needs: https://pvsol.software/en/ Hope that helps, Martin

Hello Marta, imported 3D models from Sketchup can have a variety of issues that arise due to the complexity of the model. Be sure to follow the hints here in the pdf when exporting your model: https://www.valentin-software.com/sites/default/files/downloads/sonstiges/en/3d-recherche-rev-01-en.pdf Also, in this video, there are some hints on how to work with Sketchup, so that we can import the model correctly: Hope that helps, kind regards, Martin

Hi Tim, we are in the progress to clarify some technical details in order to include ESS Home 8 and 10 into our database. It will be available soon. Thank you for your patience, kind regards, Martin

Hi Anders, there you touched the limitations of the offgrid components by SMA, that is correct. The MultiCluster Box is only suitable for PV systems of up to 360 kW. The requirement that the PV power must not be higher than twice the battery inverter power also comes from the SMA design rules. If you want to design such a big system, I would recommend to plan it in smaller parts: You have a PV power of 1714 kWp and a load of 1.62 MWh, that is set I guess. I would suggest to divide your plant in 5 sub-plants, with 342.8 kWp each, and enter a 5th of the consumption, i.e. 324 120 kWh. With these dimensions you won't run into limitations. Regarding the redox flow and saltwater batteries: Yes, we have it on our list, but we have not decided about the prioritization yet. Hope that helps, kind regards, Martin

Hi Jon, thank you for your input. Yes, we are aware of the fact that our list of offgrid battery inverters is limited to SMA products at the moment. And we definitely want to change that. I can't tell you a schedule yet but we are working on the extension of our databases, and the offgrid systems will be one aspect that we want to ameliorare. For the moment you could copy a SMA component and change the company, name and eletrical properties to your likings. Kind regards, Martin

Hi JDrojas, let me add to the comments of my colleague, that if you need the sun path at the location in question, you can see it in the results. Go to the page "Results" (Resultados) and then Diagram Editor (Editor de diagramas) and select sun height (altura del sol): Another possibility is to go to the PV module page (módulos FV), then to the shading (sombreado) and then select horizon shading (línea del horizonte). There you get the solar path diagram: Hope that helps, Martin

Hi Mohamed, at the moment we don't offer a certification service related to PV*SOL. Our sales partner in the Netherlands offer a course "Solar Specialist" with a certification included. That comprises PV system design, usage of PV*SOL and all the important things you need to know when planning PV systems professionally. But I think this will be in Dutch language. http://www.switch2solar.nl/opleidingen/solar-specialist/ What we do have are seminars and webinars. Seminars are organized either by us or by our sales partners. You can find a list of future events here: https://www.valentin-software.com/en/sales-service/product-training/seminars And then there are (free of charge) webinars that you can attend over the internet: https://www.valentin-software.com/en/sales-service/product-training/webinars Also keep an eye on the trainings of our UK partner Solar Design Company: https://www.solardesign.co.uk/pvsol_training.php Hope that helps, kind regards, Martin

Hallo Lenlo, ja, das geht. Entweder als "echte" netzautarke (offgrid) Variante oder indem du die Einspeiseabregelung bei netzgekoppelten (ongrid) Anlagen auf 0% stellst. Im letzteren Fall wäre dann das Ergebnis "Abregelung am Einspeisepunkt" die Energie, die in den Elektrolyseur gesteckt werden könnte. Unter der Voraussetzung, dass die Anschlussleistung stimmt, also der Elektrolyseur alles Überschüssige aufnehmen kann. Die Einspeiseabregelung wird vorne auf der Seite "Anlagenart, Klima und Netz" unter AC-Netz eingestellt. Es muss natürlich der Einspeisepunkt, nicht der Wechselrichter als Abregelungspunkt gewählt werden. Viele Grüße, Martin

Hi Vishal, could you elaborate on what you want to protect against over voltages? Also, how does your online course refer to T*SOL? Thanks, Martin

Hi Tim, here is a quick screenshot he sent me before leaving for the weekend And yes, after modelling in Sketchup, you import it into PV*SOL with the model import function, that is right. Kind regards, Martin

Hi Ragy, I guess that if module manufacturers know the tc of Vmpp and publish it, you are safe to use it for calculation. Kind regards, Martin

Hi Tim, we just discussed it here. We think you should go and try modelling the house in sketchup and then import it in PV*SOL. Even if you have to learn to use sketchup first, you will be faster in the long run. Modelling these types of buildings in PV*SOL with polygons will be very tricky. One of our 3D team members modelled this house in 20min. He used sketchup a lot, so perhaps you will need more time for your first models, but in the end you can really save a lot of time when you have a lot of those complex buildings. Kind regards, Martin

Hello Ragy, I would recommend to use the software (e.g. PV*SOL) to simulate the MPP voltage for a given temperature. In my opinion it is not possible to calculate it with easy formulas. If only the temperature coefficient (tc) of Voc and Pmpp are given on the data sheet, there is no way (known to me) to derive from those numbers the tc of Vmpp, except by simulating. As to your options/questions: I'd guess that the tc of Pmpp (Pmax) (in %) is always closer to the tc of Vmpp than to the tc of Voc. So, if you can't simulate, choose the tc of Pmpp. But really, in the end it is those questions why we need simulation tools in order to plan our PV systems correctly. If you want to calculate in your head, then this is ok, but be aware that the results will not be reliable. We do not recommend any other method to determine the voltage ranges of PV systems other than simulating. Kind regards, Martin

Hi Ricardo, thank you for the project files. The differences are induced by an update of the PV module data by Longi. The newer module data are taken for simulation once you enter the 3D environment. The reflection behaviour of the modules is now different which is why the simulation results are deviating slightly. That is, when I do the following, I get identical results for the inverter groups: Load the project where the whole plant with all inverters is defined Go into 3D environment, return and adopt the data Simulate Save results, e.g. for Inverter 1 Then re-enter 3D environment Delete all configurations except configuration 1 Return to main program and adopt the data Simulate See the results for Inverter 1 are the same as from step 4 Hope that helps, kind regards, Martin

Hello Infinitech, very good question, and an important one! It is unfortunately a common mistake, even among experts in the community, to mix up the temperature coefficients of the open circuit and MPP voltage. These are not the same! The LR6-60 HPH 320M module in our database has a temperature coefficient for the open circuit voltage of -116.97 mV/K, or 0.286 %/K. So the Voc at 70°C will be Voc(70°C) = Voc(25°C) + 45 K * (-0.117 V/K) = 40,9 V - 5.265 V = 35.64 V The temperature coefficient of the MPP voltage will be different, however, usually higher than for Voc. You can easily see that the temperature coefficient of the MPP voltage must be higher than the one of Voc by looking at the temperature coefficient of the power, which is -0.37 %/K. So there must be additional, temperature related losses to close the gap between -0.37 % and -0.286 %. This is why we have to simulate the module at the given temperatures we want to analyse. We take the three temperature coefficients of Voc, Isc and Pmpp and simulate the module characteristics at a given temperature, e.g. 70°C. From these curves we can detect MPP voltage and current. See here the diagram of the power over voltage for different temperatures for the LR6-60 HPH 320M module. Voc(70°C) is around 35V, as expected. The MPP voltage seems to be at 27.5 V, which relates to a relative loss of -0.425 %/K. This is where the 551 V come from, 20 * 27.5 V ≈ 551 V. The other way 'round, you can easily check that an Vmpp of 590.74 V (as stated by Fronius) must be too high to meet the condition of the temperature coefficient of the power. Simple check: Vmpp(70°C) = 590.74 V, Impp(70°C) = 9.69 A, so the Pmpp(70°C) would be 590.74 V * 9.69 A = 5722 W. This would be a relative change of -0.233 %/K of the power, so far too less. The datasheet says -0.37 %/K. Hope that clarifies the matter. If you have any question on the topic, please don't hesitate to ask. In the meanwhile, we will contact Fronius to point them out to this problem as well. Kind regards, Martin