All Activity

You're a great help Jéremie! Thank you.

Dear User, In this case, please email us at support@pvsyst.com your PVsyst LOG files (menu <File> <Export logs>) so we can analyze what happened. Best regards.

Excuse me, but this problem happens with any project.

This tool shows what happens for a specified current (i.e. imposed by the rest of the string). You can drag the red point of this forced current for analysing what happens at different values. The voltage of this point is the result of the reverse characterisics model: You can find this formula in the help https://www.pvsyst.com/help/physical-models-used/pv-module-standard-one-diode-model/reverse-characteristic-of-a-cell.html The temperature is obtained by applying the U-value on this cell, taking the dissipated power as input parameter instead of GlobInc.

Hello, the difference between the axis tilt of the field and the average orientation it belongs to is higher than the default tolerance for this parameter. You can adjust this tolerance in the advanced parameters. To find it, use the search filter and type 'tilt'. The relevant parameter in this case is 'Tracking: maximum axis tilt spread'. You can set this tolerance to 13

as we can see the three values on the figure， the V (-5.2V）,I（7.93A） and P（128W），Is there a formula that can explain their relationship，thanks！

Dear pvsyst team： I am using this software to simulate the temperature and power when a cell is local shading. I find that “externally forced current= 4.4A” is all the same for the different solar modules. What does it mean？ thanks！

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.

Hi PVSyst Team, I already generated the PVSyst report and these warnings appear during initialization. The 3D scene comes from PVCase and a TFT. Can someone assist how to deal with these errors? Appreciate your help.

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.