SHADING PROBLEMS AND DESIGN LIMITS OF PV*SOL

[David Heneš]

Question No.1

Recently, especially with the latest updates of the PV * SOL Premium software, strange things have happened to us with the shading of photovoltaic panels. In the pictures added below, it can be seen that the photovoltaic panels reach an enormous level of shading, which is unrealistic from our experience with installations. For calculations we mainly use imported 3D models from third party software in .dae format. It is possible that these errors are caused by a bad format, because there are no errors in the 3D model itself, which was compiled in SW SKETCHUP, and yet PV * SOL shows a huge shadings.

Question No.2

I would also like to ask about the design limits of the program. We are currently dealing with large ground installations and come across a limit of 7,500 photovoltaic panels installed on ground structures, which limits us in cases where we want to count power plants larger than 5 MWp. This fact is very unpleasant for us, but we are very happy to use PV * SOL premium for calculations and we would not like to change it. Is there a presumption that the maximum number of installed panels will be raised in future versions? Is this value set by the program's limits or is it limited due to the user's computers?

Question No.3

In the case where we try to import a simplified landscape model for ground installations into the program, it often happens that PV * SOL writes after manually creating the area for installation that there is not enough area on the model. Is the maximum size of the imported 3D model set for program, meaning within m2 or m3 (not meant in relation to the number of polygons)?

Thank you for your answers

[developer_mh]

Hi David,

thank you for your questions and welcome to the forum!

1) The extreme shading values that you encouter there are due to an error in our 3D environment that - unfortunately - exists quite some time already. The reason is the attica around the roof, which causes our shading algorithm to think - in some circumstances - that the roof level is actually on the same height as the top level of the attica. So for the algorithm, parts of the modules are below the roof surface, and hence the extreme shading values. They are obviously incorrect, but the algorithm is so complex that we were not able to fix this issue without breaking something else.

A workaround is to break up the attica at some point in the circumference of the roof. A small gap in the attica will prevent this from happening.

2) Find more about the limitation in this post here, point 3:

So, you can try yourself what your computer is able to manage. Also, we plan to increase these limits in the future, but the exact date is yet unknown. But for us, performance of our software is crucial. Already in the next major release we will be publishing a major amelioration for the RAM usage, so this will already boost the planning of large systems significantly.

3) In order to be able to answer that we would need a project file with the imported simplified landscape, I guess. You can send it to me here in the forum as private message, or better directly to our technical support team at hotline@valentin-software.com

 

Hope that helps, kind regards,

Martin

 

[David Heneš]

Hi,

Based on your recommendation, I have adjusted the values in the PVSOL.ini file more precisely:

<MaxAnzModule> 10000 </MaxAnzModule>

<MaxAnzPvModuleAufReihen> 7500 </MaxAnzPvModuleAufReihen>

I set both values to 10,000 and I assumed that this would solve my problem with designing large PV systems, unfortunately this did not happen and now always throws an error when taking over the project data and calculating the PV * SOL shading simulation. For better clarity, I send a screenshot of the error and I ask for advice and a solution proposal. A total of 36 SOLAREDGE 120 K photovoltaic inverters are designed in the solved project and the total installed power is 5,166.6 kWp.

For more accurate information, I am also sending the configuration of my computer and at the same time I want to ask if it is possible to assign more RAM to the PV * SOL in a user way. Also, I would like to ask why the software does not use CPU and GPU capacity for these complex calculations, as is customary with similar software nowadays.

Configuration PC:

CPU:                          Intel(R) Core(TM) i7-9700F CPU @ 3.00GHz (8 CPUs), ~3.0GHz

GPU:                          NVIDIA GeForce RTX 3060 12 GB

RAM:                          16 GB

Thank you for your answers .

[David Heneš]

I´m sending a bug report for an overview:

Program: PV*SOL premium 2021 (R8)
Program Language: cs
System Language: cs-CZ

System.OutOfMemoryException: Nedostatek paměti
   v System.Drawing.Graphics.CheckErrorStatus(Int32 status)
   v System.Drawing.Graphics.DrawImage(Image image, Int32 x, Int32 y, Int32 width, Int32 height)
   v System.Drawing.Graphics.DrawImage(Image image, Rectangle rect)
   v System.Windows.Forms.PictureBox.OnPaint(PaintEventArgs pe)
   v System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
   v System.Windows.Forms.Control.WmPaint(Message& m)
   v System.Windows.Forms.Control.WndProc(Message& m)
   v System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   v System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   v System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

-----------------------------------------------------------------------
Program version: PVSOLpremium, Version=2021.8.21415.0, Culture=neutral, PublicKeyToken=null 2021.8.21415.0
.NET CLR version: 4.0.30319.42000
Time: 2021-08-25 12:17:16 +02:00
OS: Win32NT Microsoft Windows NT 10.0.19042.0
CPUs: 8
Architecture: AMD64
Shutdown: no
ManagedThreadId: 1

    EnergySoftware.Common.BinFiles 2.0.1.1
    EnergySoftware.Common.UnitConversion 2.0.4.27808
    EnergySoftware.Lm 1.4.0.85
    EnergySoftware.Lm.Net 1.0.4.0
    EnergySoftware.Lm.resources 1.4.0.85
    EnergySoftware.MeteoSyn 5.0.31.0
    EnergySoftware.MeteoSyn.Api 5.0.31.0
    ValentinSoftware.Infrastructure.Common 2021.8.21415.0
    ValentinSoftware.Infrastructure.DataStorage 2021.8.21415.0
    ValentinSoftware.Infrastructure.IoC 2021.8.21415.0
    ValentinSoftware.Infrastructure.Messenger 2021.8.21415.0
    ValentinSoftware.Infrastructure.Resources 2021.8.21415.0
    ValentinSoftware.Infrastructure.Resources.resources 2021.8.21415.0
    ValentinSoftware.Infrastructure.Shared 2021.8.21415.0
    ValentinSoftware.PV.Calculation.Economy 2021.8.21415.0
    ValentinSoftware.PV.Calculation.Services 2021.8.21415.0
    ValentinSoftware.PV.Calculation.Simulation 2021.8.21415.0
    ValentinSoftware.PV.DB 2021.8.21415.0
    ValentinSoftware.PV.DB.Access 2021.8.21415.0
    ValentinSoftware.PV.DB.Core 2021.8.21415.0
    ValentinSoftware.PV.Desktop 2021.8.21415.0
    ValentinSoftware.PV.Desktop.WPF2D 2021.8.21415.0
    ValentinSoftware.PV.Main 2021.8.21415.0
    ValentinSoftware.PV.Models 2021.8.21415.0
    ValentinSoftware.PV.Tools.CalculationModule 2021.8.21415.0
    ValentinSoftware.PV.Tools.InverterConfiguration 2021.8.21415.0
    ValentinSoftware.Simulation 3.3.33.0
    ValentinSoftware.Simulation.ElectricalSystems 3.3.33.0
    ValentinSoftware.Simulation.General 3.3.33.0
    ValentinSoftware.Simulation.Math 3.3.33.0
    ValentinSoftware.Simulation.ThermalSystems 3.3.33.0
Open Forms:
  Form: FormMain (Visible=True)
   - ActiveControl: uc3DVisualization (Visible=True)
    - ActiveChildControl: split (Visible=True)
    - ActiveChildControl: Ut3DAnlage (Visible=True)

DbUserIds: VFS38RRS

[developer_fw]

Hello David Heneš,

the only option I see is to reduce the number of modules i.e. splitting your project into several smaller ones. The current 3D environment of PV*SOL reaches its limits with projects as yours unfortunately. The coming release in November will provide a little more headroom through splitting the 3D environment and PV*SOL into several encapsulated processes. Please also refer to this thread/comment:

Your callstack looks like a bug we already fixed so it might be very helpful if you could provide your project file via private message here in the forum.

I know those answers might not feel satisfying, we are working hard on improving the usability. If you have further questions, please feel free to ask!

Best regards,
Frederik

[David Heneš]

Hello,

we are still solving the same problem, which we have already comunicated. The solution proposed by you didn´t work for us and the problem still persists. Is it realistic for you to say when or in which version (release of the program) this bug will be fixed?

 

These mistakes very hamper us a lot at work. We encounter this problem at more than a dozen events and the unavailability of real simulated data prevents us from effectively processing energy audits for individual projects. We wouldn´t like to change programme and move to the your competition, but if these bugs are still exist, we will have nothing else left.

 

Thank you very much in advance for your answer.

[developer_mh]

Hi David,

this is a serious bug, no question. Could you please provide a project file to us, so that we can look into it? You can send it to me as private message here in the forum or send it as an email to hotline@valentin-software.com, along with your customer number and a short reference to your forum post here.

Thanks a lot, kind regards,

Martin

[Jimmy]

May I also suggest the quick fix of rolling back to a previous version that worked for David if his shading issues persist? 

[developer_mh]

Of course you may, Jimmy, thank you. It is just that nothing was changed concerning the shading calculation in the last releases, so I doubt that it would help.

[Jimmy]

Well, he did say in his first post:

 

"Recently, especially with the latest updates of the PV * SOL Premium software, strange things have happened to us with the shading of photovoltaic panels."

 

So there seems to have been a previous version that worked for him. Now, maybe they didn't update to R7/8 from R6/7 but from R3 or R4.

I just looked at you release notes while typing this and there seems to have been some changes with shading for half cell modules in R6. Although there are probably minor changes in every release that you don't type out. So maybe try to run the file in R5 to pinpoint when the issue occurred. 

[developer_mh]

Dear all,

here is the fix that helped in Davids case:

Quote

 

[...] my colleague [...] found a solution. In the 3D environment, go to the options dialog and check the following option:

Then restart 3D (leave 3D and re-open it) and the shading values should be fine.

I think this option helps to avoid the attica bug that I spoke about, where you have to make a gap in the attica somewhere. Since there is no gap in your model, the shading calculation gives unrealistically high values.

 

Hope that helps, kind regards,

Martin

[Jimmy]

Hi Martin,

 

That's a curious fix as I don't understand how these things would interact, although there are a lot of things that I don't understand so I'll just accept that it's working for David.

 

I have a question regarding that option (reduce the number of points) since I haven't seen it before now, I'm guessing that it was implemented around R3-5?

 

Anyway. What does it do? Does it apply a smoothing, flattening or decimating algoritm on the object or something of the kind? Also, does this option enable you to import models that have over 500000 vertices and PV*SOL will automatically reduce the numbers when the option is applied to get it to work? If it decimates the model, by how much?

 

All info you can give on it would be greatly appreciated as it might enable me to do less work in third party software to reduce the number of vertices on my imported models.

[David Heneš]

Hi,

I would like to ask you again about the solving the same problem that we have addressed together on this topic before. Unfortunately, your guide (enable the parameter "Reduce the number of points of the 3D object") , which was working before, doesn't work again. And software again calculate with bad shading for clarity. I would still like to remind you that none of the previously proposed solutions worked. The 3D model of the object is imported from SKETCHUP.

We actually use your software for everyday work and we are very sorry that these errors are still present.

 

Thank you very much in advance for your answer.

[developer_mh]

Hi David,

it is almost certainly that attica bug where a surrounding attica leads the algorithm to think of a closed plane over the modules. We are really trying hard to identify the problem's root, but since there are compiled third party libraries involved (DirectX), it makes it hard for us to dig deeper.

As a workaround try to add some gaps into the attica, more than 10cm wide. Ideally place these gaps in each attica section. See this thread for example (in german, but the screenshots already tell the story ):

In the end, the solution was to not only make a gap in the upper right corner, but also in the lower attica corner. Let me know if that worked.

Kind regards,

Martin

 

[Tiago Motta]

I started to frequently encounter this same problem in our projects, with the difference that the 3D models we work on are .obj files imported from drone photogrammetry models, instead of drawn 3D models.

We've already encountered all sorts of unrealistic shading frequency patterns, from 15% frequencies in areas where no shadows exist, to the most absurd cases of 99% shading. This is indeed a serious problem in 3D simulation, as it creates a constant suspicion of whether the simulation results are real or distorted by software failure. In our projects, after discovering this flaw, we have unfortunately decided to suspend the use of PVSol for 3D shading simulations until this is fixed, to prevent us from providing false generation estimate data to our customers.

It would be very important that priority be given to fixing this problem. In our case, we are already studying migrating to a competing software and also recommending this to our customers. We wouldn't want that to happen since PVSol has been our design tool for a long time and we're used to using it.

[developer_mh]

Hi Tiago Motta,

we are currently investigating this issue. The attica shading problem and the problem with obj models are possibly unrelated, though. It would be very helpful if you could provide the original obj files, along with the information which photogrammetry software you used to create it. Also the PV*SOL project that you took the screenshots of would be very helpful. Could you please send these files to our technical support team at hotline@valentin-software.com? Just add a short hint in your email that they should forward it to me.

Thanks a lot and kind regards,

Martin

[SPsolar]

Do we have an update on this Martin? We have 23 projects currently this is also doing this. Files imported from Sketch-up and nothing else around the building 45%-50% overall shading. The building next door modelled in the same way is less than 2%?

Standard pitched roof 12 degrees.

Please can we have a fix for this. 

[developer_mh]

Dear SPsolar,

yes, we have news on this. We seem to have found a fix for all those issues of high shading values, which will be released with the upcoming PV*SOL premium 2022 R5. Right now we are in the testing phase. So it would be more than helpful if you (and other users reading this) could send us the models that are causing the high shading values.

The release is planned for this month already, so if you could send the files in the next days that would be really great. You can send them either here in the forum as rivate message, or to hotline@valentin-software.com, asking them to forward the files to me (Martin).

Thanks a lot for your patience and help, kind regards,

Martin

[Radovan]

Dear developer_mh,

can you update here if the issue with 3D imported files and unrealistic shading has been resolved?

We used to have this problem too from the beginning of using your software around 2 years ago and since then completely abandoned importing 3D models because it was giving unreliable results.

But it is much more time consuming to create 3D models in native PVSOL environment. Moreover we usually have already SketchUp models done and we always remodel them again in PVSOL what means double work.

So clear statement if this issues were eliminated would help us to save a lot of time and work.

Thank you.

 

[developer_mh]

Dear Radovan,

yes the issue with the unrealistic shading values has been resolved in PV*SOL premium 2022 R5.

https://valentin-software.com/en/products/pvsol-premium/#release-notes

Kind regards,

Martin