Michele Oliosi

It should be possible in the current version of PVsyst. In the custom import window, you can choose the orientation when you have chosen GPlMeas as a variable: Please let us know if you have any trouble.

Hi, The $01 is due to a bug, the correct text should indicate something along the lines of: "increase according to global irradiance on the plane of array". Basically, it means that the temperature will increase according (proportionally to) to the irradiance on your field, i.e. the power generated. The value to be inserted is the increase in degrees per 1000 W/m^2 of irradiance. The question of outdoors or indoors is really a question of temperature control. In this case the inverters are probably subject to the ambient temperature, so ambient temperature / ambient temperature with shift are both reasonable choices.

Hi, Thanks for the feedback. Since this would be a very big change, a complete sub-hourly simulation is not on the horizon yet. However: you can already import sub-hourly meteo data, and use it to perform a hourly simulation we are currently working on a solution allowing a partial use of the sub-hourly data to address clipping losses As johank points out there are not that many data sources just yet.

Hi, There seems to be a bug in the window that we need to address, we will raise a ticket on this. In the meantime the only option would be to use the automatic filling tool "Auto attribution". As long as the lower (the ones you can see) are correct, you can assume that the others are filled along the same pattern. An example below:

You are right, they are not really the same. We will remove the "transverse incidence angle" mention.

Hi, First of all: I greatly encourage you to update to our latest version. There have been many improvements and bug fixes since verion 7.2.3. Possibly you will encounter less problems on an updated version. Second, the subarrays on the inverter SUN2000-215KTL-H3 seem to be okay, however, you first have to correct the issue (written in red) with the subarrays on the SUN2000-185KTL-H1. Indeed this needn't be a blocking message, and we will raise a ticket to address this issue.

Hi, You need to regenerate a new .MET file that corresponds to the monthly data (see the example screenshot below). In the site drop-down menu, you should find the site you have saved with modified values. You should then use the new .MET file for the simulation.

Hi, During the simulation, PVsyst considers the current temperature of the PV modules, which may be any value. The production takes into account these temperatures differences based on the one-diode model. The specific value at operating conditions (for you 22°) is just an example value, it doesn't really affect the simulation per se.

Hi Johank, Thanks for the suggestion, we'll be looking into that.!

I have added this feature to our ticketing system to be evaluated. Thanks for the feedback !

Hi, The easiest way would be to do a bifacial simulation. Whenever the bifacial model is used, you have access to the output variable: global on ground, which computes the average irradiance on the ground taking into account the shading from regular rows of tables or trackers. You can choose this variable in the hourly variables.

Hi ! Could you send us (support@pvsyst.com) your scene ? This would make it much easier to understand the geometry of your problem.!

There are basically two ways to do this. First of all you want to import your weather data into PVsyst. Then the easiest way is to make a PVsyst simulation with an output file. You can do so by going to the "advanced simulation" menu. There please define the "Output file". Among the outputs you can choose GlobInc. Once you are done, you should launch a simulation from the same "advanced simulation" window. The second way is to use the "meteo tables and graphs" window, which you get either from the "Databases" menu, or from a project by opening the meteo file. From there, you have a series of tools to display the hourly data, including the Global irradiance on a tilted plane (so you have to choose a plane tilt and azimuth). You can export the data after showing it in a graph or table.

Yes the "mixed orientation" option can be used with two orientations only. In the system window you can put them on the same inverter only if you put them on separate MPPT inputs. If not, then yes I would suggest to reduce the number of orientations to 2. Indeed, it may give a rough approximation of your output. You can also create the tables first, and then use the "orientation management" tool of the 3D scene. This will allow you to detect orientations automatically, with different tolerances. If you bring them down to two there, you may keep your 3D scene as is.

Are you using a cloud service on the folder you are storing your workspace / CSV file ? (e.g. dropbox, google drive, ...) If so please deactivate the synchronization before saving the file. Another option would be to save the files locally instead of a cloud-shared folder.

Hi linkeshd and thanks for the feedback. We will update the link in the help. When using the Sandia model for a model out of the database, one will apply the "default" parameters: b₀ = 1 , b₁ = -0.002438 , b₂ = 0.003103 , b₃ = -0.0001246 , b₄ = 0.0000001211 , b₅ = -0.00000000136 Of course it is generally incorrect to use these values.

Hi Bruno, No, for trackers we perform the transposition using only a single orientation value. There may be a way to compute this mismatch in some future update of PVsyst, but for now it would be quite difficult. You may get a rough estimate of the mismatch by using the fixed tilt option, but it probably requires to be quite careful.

Hi shubham, Yes you can do this. You can use the "multiple orientations" option in the "orientation" window, which lets you use up to 8 fixed tilt orientations. Then you can just choose a tilt value = 90° when you need it.

The shed to shed slope, is the slope in the front-back direction of your tables, usually NS direction. Your tables therefore all have the same orientation (tilt and azimuth) but are at different heights due to the slope. In the case of the baseline slope, we consider a slope along the bottom of the table, usually EW direction. Your tables effective orientation will be changed, since the orthogonal vector to your table surface does not correspond to the original nominal tilt and azimuth.

PVsyst does this rather intuitively. You can either consider the inverter as a whole and let PVsyst balance strings on inputs (good for balanced strings), or consider MPPT inputs individually. In the most simple case, for balanced strings, and if you are filling all MPPT inputs with 2 strings, you don't have to do anything special. You can uncheck the "Use multi-MPPT feature" checkbox to consider the inverter as a whole. For a more complex case, you should use the "Use Multi-MPPT feature" checkbox. In this case, for a given sub-array, you will consider single, or groups of, MPPT inputs and associate a number of strings to them. In each of these groups the strings are shared in a balanced way. In this latter example there are two strings on a single MPPT input.

Yes the latest version of PVsyst (7.2.12 at the time of this post)still assumes horizontality for the bifacial model. As long as you don't modify the parameter too far from the original 2° (it is an order of magnitude estimate, not a hard limit), the error should be minimal

As mentioned in the messages in red, the axis tilt needs to be horizontal or nearly horizontal to use the bifacial model. In your scene the average tilt is apparently 2.4°. The default limit in PVsyst is 2°. You can relax this requirement at Home window > Settings > Edit advanced parameters, but at your own risk ! Indeed, the bifacial model will anyway assume horizontal axis, so there will be a discrepancy (in the backside contribution) with the reality of your scene. This may cause some inaccuracies in the backside contribution.

Hi, Yes unfortunately at the moment it is not possible to use the bifacial model with several orientations. One way would be to do as you write i.e. split the system in two and join both results. However, this will likely overestimate the backside production : e.g. the East tables will cause shadings that impact the backface of the West tables, and vice versa. These won't be taken into account when proceeding in this way.

The thin object shading percentage is a modifier to the electrical shading factor generated by thin objects. Basically if thin objects cause a near shading factor F, the simulation will instead use 40% of F in the simulation (just as what happens with the global "Fraction for electrical effect). Once you define at least one thin object, you will be able to adapt both the main "Fraction for electrical effect" which is applied to all objects except thin objects, and the one for thin objects that is applied to the factor caused by thin objects only.

Hi, This will be taken into account in a future version, although not sure which. Most probably this will be added to a major version. I agree that it makes more physical sense. Thanks for the feedback !