André Mermoud

No, the PVsyst file organization is not customizable. You have to manually remove (or displace) files if you want to avoid them from the componernt's lists.

This file is in your installation location: C:\Program Files (x86)\PVsyst6.2.9\DataRO\ It will be recovered when you will update or reinstall PVsyst.

PVsyst checks that you have defined sufficient area in your 3D scene for placing all the modules you have defined in your "System" part.

I can't understand that. Please send me the Helios3DE files, as well as your project's file (*.PRJ) and the meteo file (*.MET), at support@pvsyst.com. And please also tell us which version of PVsyst you are using.

No it is not possible. A MPPT input should be connected to an homogeneous array, i.e. same module model, and same number of modules in series.

In the batch mode you can ask for saving the simulated results as "calculation versions" (VCi files) or not. The view of the report (and therefore the PDF) for an existing VCi file is straightforward, you don't need to perform the simulation again.

In the version 6, in the "Orientation" parameters you can indeed define "Multi-orientations", with up to 8 different orientations. If you construct a 3D representation of your system, you should indeed define fields in different orientations, compatibles with your "Orientation" and your definition of the number of modules in your "System". There is no limitation about the orientations differences as a shading table is now computed for each orientatin independently. Now when you define rows following a terrain you can indeed have several different orientations. In the present time this situation is only taken into account with 3D scenes imported from the Heliod3D program. In this case PVsyst will define an average orientation for use in the simulation. In the 3D editor, you will have a tool for the analysis of the distribution of the orientations of your tables. If the orientations distribution is too large, you have the opportunity of modifying the limits in the Hidden parameters (see the Help), at the price of a slightly lower accuracy of the simulation. We are now preparing the representation of a terrain directly in PVsyst without passing by Helios3D, and these possibilities will also be available in this new framework.

This is an excellent question. In the present time, PVsyst provides a pre-sizing of the battery capacity, which is computed using one meteo yearly distribution (from monthly meteo data). This yearly meteo is randomly generated (synthetic generation), so that you have a different result at each execution. The PLOL is highly dependent on the worst conditions, i.e. the duration of the periods without sun in the meteo series. We plan, in a near future, to extend this sizing evaluation over a set of multiple years generations, and give a distribution of the PLOL, allowing to establish a P90 (or any Pxx) probability. NB: if the battery is slightly oversized, for a given charging/discharging balance its lifetime will be extended. Therefore the higher investment price will be balanced by a lower "operating" cost (i.e. provision for the replacement of the battery). The important parameter here is the cost of the stored kWh, taking the number of cycles into account.

I don't see how to simulate such a special configuration in PVsyst. I didn't foresee the possibility a defining a transparent object. Defining thin objects are possible also with parallelepipeds, in any version. I didn't remove any possibility about this since it was implemented. However this is not a good way: the "thin object" definition is really for taking the size of the object into account, for the electrical losses. If you define a glass as a thing object, it will produce a 100% linear shading (as an opaque object).

In the present time, it is applied to the inverter output, and with an identical relative Pnom reduction for each inverter. We have indeed to do some developments for appliying it to the E_Grid value, and balancing it between the inverters if the sub-arrays are different. This is a not trivial modification of the simulation process, because we have to compute the full system yield before applying the reductions of power. This is on our ToDo list.

See the Help "Project design > Concentrating systems". In the CPV definitions, you have a "full acceptance angle" and a "null acceptance angle" (here angles are cone radius). This defines a trapezoidal acceptance function (usually less than 1° aperture). All beam rays outside of this acceptance function will be lost. - In the simulation, this is the case when the trackers attain their mechanical limits. - Moreover, in the reality there may be tracking inaccuracies (for example due to wind). PVsyst doesn't take these unexpected effects into account, very difficult to evaluate.

If you have a multi-MPPT inverter, no problem, you can define a sub-array per MPPT input. If it is on one only MPPT input, it is not possible in PVsyst.

For usual meteo data, the "official" altitude according to WMO standards is 10m, without surrouding obstacles. Now in PVsyst, if you have values measured for instance at the array level (or 1m above), the velocity values are about 30 to 40% lower, so that the Uv parameter should be increased by this amount.

Yes, PVsyst includes the Meteonorm and the NASA-SSE data, for anywhere on the earth. Please see our FAQ Which meteo data are available in PVsyst ?

You can determine the discrepancy by yourself, by defining your field - either as a whole, - and as seperate PV modules (one rectangular field per module) if they are significantly spaced (and not too numerous).

If the module is not in the database, it can have been defined by the mentioned third-party. - Either you got the project as PVsyst source (PRJ and VCi files). If the sender has exported the project by "Files" / "Export projects", the PAN file should be in the project's data. - If not, you don't have any mean of recovering this file. You should redefine this module (PAN file) from Datasheets information, and you are not ensured that the "uncertain" parameters like Rserie and Rshunt are the same.

I can't understand that. Please send your full project (using "Files" / "Export projects") to support@pvsyst.com.

The batch is meant for analysis and comparison of several executions one with respect to the another one, and for any specified variable. There are hundreds of ways using this functionnality. I really don't see how to present a meaningful report.

This configuration is not possible with PVsyst. The master/slave functionnality is only useable within one given sub-array. This limitation is quite understandable: if you connect your inverters in Master/Slave mode, all the PV sub-arrays will be connected together as a same array. PVsyst (and the best practices of PV) cannot manage heterogeneous arrays, i.e. array with different modules and/or different numbers of modules in series. Be careful with your strings of 20 Trina and 18 Renesola modules in parallel: the operating voltages will not be the same, you will have a significant mismatch, and you can get double Maximum power points, with the risk that the inverter chooses the lower one.

As I asked after the previous question, please send me this MET file at support@pvsyst.com

This is the right way: on a given sub-array, you can only define homogeneous arrays (i.e. same PV module model, same number of modules in series). Now if you define an "normal" inverter with 2 MPPT, the report will mention one inverter and 2 MPPT. In this case the 2 MPPT inputs will be considered as 2 identical half-inverters In your case you have specified "with unbalanced inputs", I don't know why. This is a very special case (suited for special inverters). With this option the MPPT inputs are specified as "Main" and "Secondary" input. In your system definition you have to define a sub-array for each of these inputs. If you define 2 "Main" inputs, this will mean 2 different inverters.

The choice of a project or a meteo file may become slow when the list is long, i.e a common list of projects shared by many people. Because each file of the directory has to be open for extracting information for the list. And this is still made worse if the access is through a network. However this reading is normally done once only for each run of the software. A solution could be to remove the old projects or meteo files (no more in use), i.e. to store them in an archiving data structure. In "Files" / "Workspace", you have the opportunity of easily switch to another data structure.

The Uc and Uv parameters are not related to the location nor climate, but the mounting mode of the modules (if they are integrated - i.e. back insulated - or not). Now we don't have really well assessed values for these parameters. Please see the Help, available by F1 when you are in the U-definition dialog.

This is indeed a bug: I have forgotten updating these 3 labels (Transposition FT, Loss and Global on coll. plane) in the multi-orientation panel. I have corrected for the next version 6.27, to be released within 2-3 weeks. However these are just values shown as information when choosing an orientation: these are not used anywhere in the simulation.

I don't know, I have never implemented the NREL algorithms. The fact that the differences are rather "symmetrical" around 12H indicate that the problem is probably related to the time definition. The sun progresses by 15°/hour (along its trajectory). Therefore a discrepancy of 3° in the morning may correspond to a very high time discrepancy (3°/15° corresponds to 12 minutes, to be divided by cos(slope of the trajectory at sunrise) ). However in subtropical geometry (trajectory almost "vertical"), I don't understand well how you can get 3 to 5° error at sunrise. The problem of the accuracy will mainly arise if you perform a retro-transposition for getting the GHI and DHI from a measured DNI value. The morning DNI calculated from the GHI and DHI may have a significant error, but without consequence on the incident irradiance on your almost horizontal plane. PVsyst provides the opportunity of specifying a time shift, already at the meteo data import time, which can avoid this problem.