All Activity

Just bumping this for visibility. I'm still looking for some help with this. Thanks in advance!

I don't know what you have defined as Charging device power in the Grid storage dialog. Probably around 100 kW. Now I see that these hourly values correspond to a power of 1.4 kW, i.e. 1.4% of the nominal power. At this power level, the inverter efficiency profile (defined by a maximal and EURO efficiency) is very low, close to 0.

Hi Vamsee, Unfortunately, the issue with PV Fields not receiving shadow when they are set as non-casting object is still present in the latest version of PVsyst. For the PV fields to receive Shadow the PV itself need to cast Shadow (Shadow casting ON). Can you set your PVs to cast shadow? Regards, Eric

Hello, I made a simulation with Luna2000-200kWh (and a PV field of 100 kWc) with a self-consumption scenario. When there is no PV production and no User consumption, I see that the battery is in Discharging mode with a very high consumption of battery inverter : 1,4517 kW (CL_InvB) compared to the PV inverter consumption : 0,0023 kW See below the result file : How is calculated the CL_invB value ? Is it possible to parameter it ? Thank you

Hello, the map of the newly created site in version 8.0.12 is not available，8.0 Other versions do not have this problem

It uses the last two points.

PVsyst usually takes the minimum pitch as default value for the backtracking algorithm. If only one of your trackers has a pitch of 6.24 this may explain what you observe. Note that you can anyway override the backtracking parameters from the 3D scene > Tools menu > Backtracking management.

Hello, I suggest that you run a simulation with the bifacial parameters and export an hourly output file with all the relevant parameters, such as overload losses etc. This can not be done for individual strings but for the full system. Running several iterations should give you a good estimate of the losses.

Hi Linda, Thanks for the response. The requirement arises in order to optimally size no. of strings to MPPT of central inverter while complying to maximum current limitation of MPPT. Since the rear side current in bifacial is highly variable parameter I wanted use PVsyst to get fair estimation of it so that MPPT can loaded optimally, avoiding clipping losses. Can you suggest some solution here? Also can we find the single string current from IArray with total no. of strings

My PVsyst report is showing a pitch of 6.24 even though I have set the pitch to 6.25 in the Shading Scene. How can I fix this? Thank you, Vera

Is this resolved I am also facing the same issue. Object shadings are being considered and the adjacent tracker shading is not being considered. is there any work around.

Thank you for your response. Does the linear extrapolation you mention use all points or the last two points of the table? Regards,

Hello, The most straightforward way to evaluate bifacial gain is to run two simulations: one with bifacial parameters activated and one without. While the current itself does not differ between the front and rear sides, the rear side does contribute to the overall energy production. In PVsyst, the results are presented for the entire system and not broken down per string.

Hello, PVsyst is calculating the sun position based on the exact year accounting for leap years, when specific years are simulated. Thus, if you import a specific year that is a leap year though the 29th is missing in the data set, it will be considered as missing data and values will be 0 (similar to as if any other date of the year was missing). So values for February 29th will be zero (e.g., no irradiance), but the date will still be included in the simulation. March 1st will correctly follow as the next day.

Hello, You can read about how to adapt you PVsyst simulation to a floating system in the following post: https://forum.pvsyst.com/topic/1346-how-to-adapt-pvsyst-to-floating-pv-systems/

Hello Tyler, Essentially, the Global incident in the collector plane will be calculated for each sub-array for the assigned orientation (or possibly a mixed orientation). The GlobInc as the total result is an weighted average based on the Pnom PV

Hello, You can use the lasso selection (Ctrl+Shift+L) to mark all the tables that belongs to the concerned orientation and in the "List and management if objects" window (Ctrl+G) you can change the orientation of all the marked tables.

Hi, I am trying to understand the Bifacial gain for my system in terms of electrical output for each string. The simulation results gives me I (Array) which i think is total Imp of plant both including front and rear contribution and not on string level. I understand PVsyst follow one diode model for Bifacial module but still is there any way PVsyst providing the value of this rear side and front side Imp separately for each string.

If I want to simulate FPV system in PVsyst, for the temperature coefficients Uv and Uc, how much should I insert for each value?

Hi Linda, I'd like to circle back to the original question, as I have a similar project with multiple azimuths and tilts, resulting in eight distinct array orientations. Since there is only one GlobInc value on the 8760, I am trying to determine how that GlobInc value is calculated. Is it a weighted average based on the DC capacity per each orientation? Thank you.

Hi, thanks for the answer. My problem is that when I import the pvc file with the shading scene I do not know how to associate the different pitch to the two system sub-arrays. Like in this case, I have already created two sub-arrays in System design for the two pitch values, but how can I associate them correctly? If I click on one of the two group of the 3D fields, it highlights a mix of trackers with the two different pitch values.

Yes indeed, one only other user reported this error. The error is indeed the unit's name, which should be MWh/year. With this the value itself is correct. I really don't know the origin of this error. I tried to secure some initializations, but I really cannot reproduce this problem, so that I can't be quite sure that it has been corrected. The user who had reported it cannot reproduce it, too. If you get this problem in a stable way, please send us you whole project, using "Files => Export project" in the main menu. Please send it to support@pvsyst.com.

I have a variant of a project in which the 8760 file shows that E_Grid column is not reaching the defined "Grid power limitation" of 25 MW in "Energy Management" and yet there is some energy discarded as EGRdLim in the 8760 file. What makes it more confusing is that I'm copying from a variant that is working well, and just changing the orientation to domes. I'm attaching a capture of some of those cases. Any thoughts on what I may be missing? Thanks!

Hi Greg, In PVsyst the grid-tied systems with storage will never charge the batteries from the grid. The non-zero values for EFrGrid are situations where PV generation and battery discharge together are not enough to cover the load, and therefore power needs to be imported from the grid. This typically happens at the end of the night and early in the morning when batteries may be discharged and PV generation is still low. It can also happen after a series of cloudy days that did not allow to fully charge the batteries.

Hello, It seems to be linked to one of the new tolerances put in the new version that when the angle between your average orientation and at least one of your PV table is too high compared to the settings of your projects. To fix this error you need to increase this tolerance. From the main window of your project, click on "Project settings" at the top of the screen: Then you need to select the "Other limitations" tab and increase the value of the "Maximum orientation difference for defining average (spread) orientation" parameter: Once the value has been increased the error should disappear.