MicheleANE

Hello again, This seems to be solved. It was probably on Meteonorm side, sorry. Best regards

Hello, Both using version 7.4.8 and 8.0.3 the import of Horizon line from Meteonorm API doesn't work. It seems the API is replying with "failed". Best regards

Hi, I am trying the ver8 now and noticed that, after creating a 3D scene and running the shadings calculation by clicking the Table button, when I close the table window, the software tells me to press table again. Also, if I ignore this and close the Near Shadings window it tries to run the calculation again and then, even after running it here, when I press Run simulation button, it runs it again. For now I'll just skip the first 2 times and run it in the end so it gets saved but please advice. Best regards

Hi, What you measure on site should be as close as possible as this GlobInc. Meaning that pyranometers should be installed with the same orientation of the arrays and they should receive no shading. Of course you can't avoid Far shadings from mountains and that is why, when comparing simulation and measured data, you should exclude that loss. Hope this helps, best regards

Hi, Sorry to intrude this topic. We also often Face this issue. While it's possible to adjust the loss by changing the length, the end-user will read on the report a value for the thickness that is not the real one and often ask us the reason. Would it be possible to allow custom sizes or maybe allow to define other sizes in a separate file? Best regards

Hi, While there is no template system, you can make a template-like variant in a project and then when creating a new project you can import that variant as a base. Hope this helps, best regards

Dear Linda, While it's true you can import GTI data this way, I believe PVsyst will once calculate GHI from this imported GTI and then calculate GTI internally. This 2 GTIs will probably differ by some value. I think Florent was asking if it's possible to keep the exact values as imported. Of course correct me if I am wrong, best regards.

Hi, When comparing simulated data with measured one, it would be great to have the possibility to input degradation loss monthly and have the software use those numbers as they are (no averaging). Another option would be to have the degradation loss actually change during the year. Example: Starting degradation set as 0.5%, Yearly degradation loss set as 0.365% -> each day increase the degradation by 0.001% so -> 0.501%, 0.502%, ... Best regards

Hello, Just to add some to this. This effect is also present, in a more limited form, in large scale plants on hilly terrains. In most cases small tables are used to better adapt to the terrain and strings are made up of several arrays. In these cases there will be a mismatch of current because of the different POA irradiation in these several tables. It would be fantastic if this could be calculated in PVsyst. Best regards

Hi Michele, Thank you for your response. It is nice to know this is being given thought. Couldn't ask for more. Best regards.

Hello, Any news about this? 2 decimals are more than enough. Just, please make it so the parameters inputs are 2 decimals as the results and that those 2 decimals are kept the same for losses that are directly calculated using those parameters (ex.: soiling loss). Also, recently I noticed that the mismatch loss keeps the input value only on the first run of that variant. If ran twice, it will sometime change (usually x-0.01%). Best regards

Hello, @dtarin We usually don't use the internal tool to fit arrays on terrain but this could be an idea for a workaround: Instead of using trackers from the beginning, fill the areas with fixed tilt arrays of the same size of the trackers and use an azimuth that gives you the same shape of the trackers (SN axis -> 90 degrees azimuth for fixed tilt) and tilt equal to the max tilt of the trackers. After positioning them convert them to trackers with the internal tool and they will keep the SN slope too. Best regards

Thank you for the prompt response. I perfectly understand your point about accuracy and agree. It's more about coherence and being able to show that we used the input values as requested. It would actually be fine if all losses and inputs were fixed at 2 decimals without other options as long as they were all compatible. Thank you in advance for your support and best regards.

Hello, We are able to display the report using 1 to 3 decimal places but, in several places of the software, the input is limited to 1 or 2 decimals (soiling, aging, etc). Often we are requested to run simulations with input values calculated separately and, as they are often given with 3 or more decimals, it would be nice to be able to keep the same precision in the input and output. This is especially true for losses that just use the input value. These should not be rounded more than the report precision requires. Best regards

Thank you for the prompt response. I understand that the effect is very low. The problem is the consistency of the rounding. It would be fine if it always rounded to 0% or as normally if >0.05 then 0.1, if<0.05 then 0 or also always to 0.1 Also I don't really see the need of rounding these numbers. Wouldn't be even easier to just keep them as they were input? Sorry for being pedantic but we were asked this by customers and we are not able to give them an answer. Best regards