All Activity

Hi, It was indeed possible to define situations with only a single row + 3D scene + bifacial model in previous patches. However, this was not the intended behavior and was a possibility that was exposed by a bug. We would not be able to guarantee that the calculations were properly handled in this situation. We have recently corrected some issues in terms of number of rows, and that has had the effect that the above unwanted exposure was corrected as well. Currently, the calculation with a single row in an orientation (such as your orientations 2, 3, 4, and 5) can only natively be realized with an unlimited orientation. There are therefore two workarounds: Model orientations 2-5 as unlimited orientations with one row. Duplicate the 3D tables from orientations 2-5 and any objects that may shade them. The duplicates should be placed far enough on the scene so that there are no unwanted interactions. In this way, PVsyst recognizes two rows instead of one. Since they are sufficiently spaced, mutual shading effects are negligible. You may need to alter the following advanced parameters (Home window > Settings > Edit advanced parameters) to avoid some problems with a larger scene than the modules defined in the system window This solution does not work with Module Layout definitions (because these necessitate a perfect match between 3D scene and system) Please note that supporting 1 row bifacial orientations is in our internal roadmap, and I will rebound on your request with discsssions to see whether we can anticipate this feature a little.

Hello, In general it is fully possible to continue a project made in 7.4 in version 8.0.

Hello, When PVsyst 8 was released I was able to run a complex carport PV simulation using the bifacial model (see attached report). It consists of 2 orientations but actually I defined 5 orientations because although the southern carports share the same orientations, their table widths are different. I took advantage of the new bifacial model features of PVsyst 8 in regards to the pitch and number of rows defined by the user for the cases when you don't have an unlimited-sheds type of array. However, now with 8.0.13 version when I try to run again the simulation (because I need to get an 8760 file), I'm not able to run the simulation with the bifacial model anymore. I got the following errors for all orientations except for orientation #1. I don't understand why I'm getting this pushback, when we haven't modified anything to the original PRJ. In fact, when I try to modify the bifacial model values (such as tilt, pitch, width, and so on) for those orientations, PVsyst doesn't save that information and applies a generic 25° tilt a 0° azimuth, when in reality all arrays have a 5° tilt in System and 3D definitions. See an example for orientation #2 (-41.5° azimuth). I would really appreciate any advice on this issue. Thanks! MoCo 6th District Police Station V6.VC0-Report.pdf

Good morning Michele Thank you for your valuable advice. I wanted to know if the time series data on snow depth can be reflected in the albedo, so I understand now. For the warning on the clearness data, I will email the files you pointed out to support@pvsyst.com. I will probably send it to you within 24 hours, so thank you.

I just upgraded PVsyst from version 7.4 to 8.0. Can I open the PVsyst files created in version 7.4 with PVsyst version 8.0 or do I need to start from scratch?

The transfo loss reported by the simulation (loss diagram) is the sum of the Copper losses and the Iron losses. Remember that the Iron losses are a fixed value, permanent (24/24) if you did not check "Night disconnect". It represents an important contribuition.

Indeed, the hours where the wind exceeds the given threshold, the simulation will be done with the trackers in the defined wind stow position. You will not directly see any losses in the diagram though indeed it will result in a less optimized Global Incidence Irradiation. To properly evaluate the impact from the wind stow, you would have to run one simulation without activating this functionality and compare the two simulations.

Hello, I recently found that the MV transfo loss in the loss diagram is somehow larger than the value I defined in the ohmic losses section, for example in the datasheets data, I defined the global loss at PNom to be 1.01%, but the MV loss in the loss diagram shows 1.4%. Since the Operating power of MV transfo is sometimes lower than PNom, MV transfo loss should be lower than 1.01%? Do you have any idea about this? Thank you!

Good morning everyone, I would like to ask how can we determine the average degradation value and the Imp/Vmp RMS dispersion of the pv panel? I am using LongI LR8-66HGD 620Wp model. All reference are welcomed. Thank you for your time.

Hello Mr. Lang. As requested I sent the exported log files. Hope they help. Let me know if you find out anything. Thanks,

Hello, In general, far shading affects the entire PV field uniformly — at any given moment, the sun is or is not visible on the field. As a result, it can potentially reduce the impact of near shading, since far shading may occur during times when near shading would otherwise be present, typically when the sun is low on the horizon.

Hello ! Regarding the snow data, actually the snow depth time series data is not used by the simulation in PVsyst. Instead, the impact of snow is present via the albedo factor (monthly). Typically, if snow is present on the ground, the albedo factor is between 0.4 and 0.8. You could check how many days are snowy in a given month, and proportionally increase the albedo. For the warning on the clearness data, we would need to take a look at the data. Can you send the data and MEF file to support@pvsyst.com? Else, you can share a screenshot of "Best clear days Ktcs" graph and "Monthly best clear days"? That will also help.

Dear S. Oviedo, Please email us your PVsyst LOG files (using menu <File> <Export logs>) at: support@pvsyst.com so we can analyze what happened and try to reproduce the issue you reported. Best regards.

Dear PVsyst Support Team, I’ve encountered an unexpected behavior in the simulation results. I applied different Far Sahding horizon profiles to the same project, while keeping the Near Shading scene exactly the same. However, I noticed that the Near Shadings losses changed depending on the Far Shading configuration. Could you please clarify: Does the Far Shading (horizon line) influence the calculation of Near Shading losses? If so, is this due to how diffuse or albedo components are modeled in the Near Shading algorithm? Are there known changes in this behavior across different versions? I would like to ensure that my simulations reflect shading losses accurately without unintended overlaps or misinterpretation. Thank you for your support.

Greetings 😁 As mentioned, I've done a licence transfer from one pc to another (Did a clean format and decided to switch). After (correctly?) selecting the desired workspace folder (Same as always, it's in Onedrive's cloud), PVsyst finished installing and almost everything works fine, projects show up, reports, etc. The issue is, when opening 3D scenes which had ground images before, they wont show up. ("PVsyst couldn't find the ground image file: .... Do you wish to delete this object from the shading scene?") Sorry it's in spanish Ground image file is still being searched in the previous pc directory. It just looks in an unexisting directory. Is there a workaround for this? Anything I can try? Thanks in advance,

Incidentally, it is possible to upload the original METPV-20 data (public data), the data formatted for loading into PVsyst, and the MEF file used to load into PVsyst. Could you give me any useful recommendations from these?

It was easy to organize the METPV-20 data and import it into PVsyst, but I keep getting a warning that the clarity index is too low compared to the clear-sky model. I haven't yet made use of the Best clear days Ktcs graph.

Good morning. I have been involved in the development of solar power plants in Japan for over 15 years. I have recently been operating a small bifacial vertical solar power plant in Hokkaido, a snowy region, and have experienced the snow albedo effect. So I am continuing trials to incorporate NEDO's METPV-20, which also includes snow depth data, into PVsyst. Has anyone been successful?

So I have to work the profile as .CSV File If I want to seperate the profile for all month right? That's fine then, Thank you very much!

With the option "Load values from a CSV hourly file" you have full liberty to define the load profile exactly how you wish.

Do I have to used Monthly normalizations in order to input the daily hourly profile for every month? Seems like they still using the same Load Profile and change the values for each month based on how many days in the month. I want to input the profile for every month without them connecting like this.

Hello, In the version 8.0.13 we corrected a bug and a daily hourly profile is now normalized and saved properly. You also have the possibility to import a .csv file with hourly values for the full year. The different ways of defining a self-consumption profile are further described in this youtube tutorial:

Hi there. I have many projects that require me to use PVsyst to simulate PV systems. In some cases, I also need to add the consumer's load profile. Every time I do this, I have to use the Seasonal modulation feature, where I group the load profiles by sets of months in order to input the data. Is there a way to add a daily load profile with hourly values for each individual month? I tried using Monthly normalizations, but it ended up applying just a single profile to all months.

To simulate how the panel will perform, you’ll need to use specialized software like PVsyst, PC1D, or COMSOL. These tools help you understand how much electricity the solar panel can produce under different conditions.