All Activity

Hi dtarin, I updated that but I still get this error: Thoughts? Can I send over the project file for your take on it?

Try updating this.

Yes, that's correct. The site I was working with had the trackers tilted on the terrain with different tracker heights and axis tilts. The custom diffuse tracker that I had selected in version 7.4.8 worked with the selection of adjacent masking trackers. But after importing the project to version 8.0.9 the masking selection did not select the adjacent trackers and I had trouble getting that to work.

Thank you for reporting this problem. It will be fixed in one of the next PVsyst versions.

Dear User, You can use PVsyst menu <File> <Export projects> to easily export your project files in a ZIP file and email it to our support address: support@pvsyst.com with your PVsyst LOG files (menu <File> <Export logs>) so we can analyze what happened. In the meantime, you can already read our FAQ about the most efficient way to optimize PVsyst simulation time: https://forum.pvsyst.com/topic/3542-how-to-optimize-simulation-time/?do=findComment&comment=9867 Best regards.

Good day! I have a 32 core processor but cant use it for full power( Every time when I try to turn on "Enable multi-threading" flag PVSyst stop working without any crashes. When I try to open any project its freezes in endless loading. When this option off program working well, but calculations calculations are sooo slow. How can I fix that?

dtarin, Thanks for that suggestion, I have since updated the model using zones, selected auto tilt, adjusted the spacing between modules to 0.009m (0.375" for module to module gap. I found it easier to forgo the masks for most of the design and just deleted the modules away where necessary. When leaving the shade scene I get the following error: PV field is confused with, or very close to the object. I do not have other shading objects, the fields are all above 0.05m (so as not be be obstructing with the roof) This was setup using auto fill with my spacing of 0.009m module to module gaps, but is this too small for PVsyst? What options do I have so as not to give bad bifacial gain representation between the module gaps and such? Thanks again for the help! Kind Regards, Mike

Hi Auriane, I have since made change to that variant, and when re-running it I am not seeing anything as extreme as the situation I posted above. However, there are still some very fast drops from almost max power to very low power (but not zero). I have sent across the project files to PVsyst support email anyway for you to investigate. Kind regards, James.

Hello, to better assist you, please send your project to support@pvsyst.com

First of all: the value 1.9% is related to the total energy flux of the system. The real "round trip" efficiency of the battery pack should be related to the energy passing through the battery. This is mentioned as 5.3% here. I don't know where your affirmation of 85% comes from. This is extremenly fluctuating according to sources. Some Li-Ion battery manufacturer mention 95% on their datasheets (which is probably not realistic), others 90%, rarely less. Due to the extreme complexity of the battery model, especially the SOC evolution according to the charging/discharging balance, the determination of the battery efficiency cannot be quite reliable in the PVsyst simulation. This issue is fully explained in the help https://www.pvsyst.com/help/physical-models-used/batteries/battery-model/battery-efficiency.html?h=battery+efficiency

Dear PVsyst Team, We have a question regarding the battery losses displayed in the simulation output. The BESS loss parameters in PVsyst appear to reflect only certain categories of losses, and in our case, the "Battery Global Loss" is shown as approximately 1.9%. However, since the round-trip efficiency (RTE) of the battery is around at 85%, we would expect the total battery-related loss to be closer to 15%. Could you please clarify why only 1.9% is reflected in the simulation report? Is there a reason the full impact of the RTE is not shown under the battery loss section, or is it accounted for elsewhere in the system losses? Appreciate your guidance on this matter.

Geometry Dash Scaling module dimensions in the PAN file does not directly affect energy output—it mainly affects shading calculations and layout visualization. Energy yield depends on electrical parameters, not physical size. In contrast, specifying collector band width (used in 2D shadings) does influence energy results, as it determines how much of the collector surface is exposed or shaded, directly affecting irradiance and losses.

Good morning PVSyst team, always thanks for a solution.. For dome project (attached image of 3d scene), It seems really difficult to adjust bifacial system for it. An error message said, "tables width are not same" or this system is not suitable for bafacial system. Is there anyway i can reflect bafacial system for this proejct? I'm also considering to run pvsyst individually but even i did it the same error message comes out. Pls guide me, thanks

Hello Chen, We did not carry out dedicated studies on how array pitch affects the heat dissipation. However, the thermal losses are indeed influenced by the PV module support structure and it affects the convective cooling on the back plane. The advised U coefficients corresponding to each structure type are described here: https://www.pvsyst.com/help/project-design/array-and-system-losses/array-thermal-losses/index.html#u-value-determination It is also possible to measure the U coefficient values for your installation as explained here: https://www.pvsyst.com/help/project-design/array-and-system-losses/array-thermal-losses/u-value-measurement.html

Hello James, If the dip in irradiance is not due to missing data, I would need your files to look into this issue in more detail. Could you send your project at support@pvsyst.com ? Auriane

Dear Oli, Unbalanced inverters are not designed for power sharing. Regards,

Hi Linda, We tried PVGIS and Meteonorm and saw similar anomalies on different days also. Weather data imported from those 2 sources shouldn't have missing data however? James.

sorry ，i find a mistake in my sentence，the solar size is 210mm*105mm，so final result is 44/ ( 0.21*0.105*29) =25 = 94 （℃）.The results are basically the same as those of pvsyst.

just choose "Generic_Mono_700W_Half_Bifacial.PAN" for example. Here, Uc = 29 W/m²·k, or say Uc = 29 W/m²·℃, and the size of the cell is 150 mm*210 mm. For one solar cell shading, if the temperature rises by 1 ℃, it need power 0.21*0.15*29= 0.9135（W），and the cell power consumption now is 45W，45/0.9135= 48.17 （℃），by adding 25 ° ambient，the result is 73.16（℃），which is not quite consistent with the results shown on the graph （95℃）.Can you help me check if there are any errors in my deduction？ thanks

I don't have any the details of this system and haven't modeled solar edge in a long time. However, with a zone you can auto set table to fill the zone, auto tilt to adapt to slope of roof, set table size to 1x1, and then use module layout for allocation (electrical loss). Keep in mind this is just for shading calculation, not power, so you don't need it perfect. As long as it is reasonably close to capturing the shading conditions it should be fine. You create a single zone, insert masks, auto fill the zone as shown. This will allow you to model bifaciality.

Hi dtarin, thanks for the input. I can make a zone in a similar shape as the polygonal field, but when defining the Zone's Field Properties, I can only do a singular rectangular array - are you suggesting that I would have a bunch of little zones where I would need to align / elevate and line up each one in order to mimic the flush to roof mount shown above? The other factor that might complicate this the client wishes to use SolarEdge for this layout - not sure if using the zones in this manner would not be advisable then - ie defining the Module Layout's strings per inverter? Thanks again for the help and insight, much appreciated!

Hello, When working with a normal ground-based project, in "Weather data tables and graphs" , in both "Graph" and "Tables" tab, when I try to check for the monthly values of GHI and GTI, very often I see both values are the same, which is weird. Also PVsyst asks me for confirmation of the Plane Orientation, which I have already defined in System. Only when I try to see the value in Hourly, then it displays correctly , and then go back to the monthly values in both "Graph" and "Tables" tab, they will be display correctly. Steps: 1. Try to see monthly data, PVsyst ask for plane orientation 2. Monthly GTI = GHI ?? 3. Same when seeing in Table 4. Only when check the data in hourly mode, it seems to "fix" the bug 5. GTI and GHI in Graph and Table now correctly displayed

You can use draw a zone in the shape of the area with PV tables that will allow bifacial computation.

In this tool, PVsyst tries to evaluate the temperature of the reverse-biased cell, as a function of the power consumed in this cell and the U-value (with resp. to 25° ambient). In this case this is not dangerous, but in usual modules the cell temperature may become very high: this is the hot spot problem.

it worked. thanks for your quick reply.