kjs55

Suggestion is to add one decimal place (significant figure aka significant digit) to the azimuth and tilt in the PVsyst output report PDF (instead of rounding to the nearest integer) to match the inputted azimuth and tilt model parameters in the PVsyst model.

Please add a "Clear Formatting" option to the PVsyst Forum. e.g., When you paste content into a new forum post and then add a carriage return somewhere within the text, it results in extra line spacing. It'd be helpful if we could then highlight the entire text and click "Clear Formatting", so we can resolve this formatting issue.

A useful starting point would be a clear specification of the measured GPI (see my comprehensive list of real-world options above). Namely, please instruct us clearly on how to properly measure GPI data for application/import into PVsyst. I thought at one point I'd seen it written that the measured GPI data must be entirely unshaded (within geometrical/physical limits), but I just looked through the PVsyst Help Menu, and I can no longer (easily) find this instruction (so perhaps it never existed). Considerations: - Monofacial (front-side irradiance only) vs. bifacial (rear-side irradiance also) - Pyranometer (dome-shaped) vs. reference cell (flat-glass) - Shaded vs. unshaded Keywords (search terms): ASCII text file Back-side irradiance Bifacial Custom file import tool Dome-shaped Front-side irradiance Global Plane-of-array POA Irradiance GPI Global Tilted Irradiance GTI Incidence Angle Modifier IAM Measured data Measured GPI Meteorological meteo weather data Monofacial PVsyst Pyranometer Rear-side irradiance Reference cell Shadings Sunny-side down Sunny-side up Unshaded

I think it would be a useful feature to allow the custom import and direct use (simulation) of measured weather data (without hourly averaging). I think it would be relatively straightforward to write a PVsyst wrapper where the data is preprocessed into several 8760s on the front end, run through the core PVsyst tool as normal, and then post-processed on the back end. Namely, 1-min. measurement data is split into (60) 8760 files, 5-min. data is split into (12) 8760 files, etc. on the front end. Then, normal PVsyst is run over a loop (60x or 12x, respectively), with the appropriate time shift for each run. Then, the resultant output files are recombined on the back end (back into a 1-min. or 5-min. data set, respectively). In other words, there are really no major changes to the core PVsyst tool needed in order to implement this feature to enable simulations of (at least) custom, imported subhourly measurement data. Thanks.

Help Menu Navigation: Project design > Shadings > Calculation and Model > Treatment of the Diffuse component > Global calculations on diffuse Emphasis mine (bold italics): """Therefore for each direction, we should evaluate the product of the Far shadings, Near shadings and IAM loss as parameter for the integral. Along with the last irradiance loss (soiling, independent on the direction), this leads to a constant global loss factor for diffuse, used for the calculation of the "Effective diffuse" component in the simulation.""" The use of the word "should" here leaves me w/ the question: Would you please confirm that Near Shadings are included in diffuse irradiance shadings? Even for unlimited sheds, i.e., not only for 3D scene modeling? Many thanks.

Would like the option to time shift imported data by, e.g., 2.5-min. (or 7.5-min., etc.). Presently, it appears PVsyst only allows imported data time shifts in integer intervals (increments).

Sorry, I must have made a typo. I meant to say that I'd like the option to set Energy units to Watt-hours Wh in this GUI Window #1: 1. PVsyst > Settings > Preferences > Default values Presently, you do have the option to output data in Watts (Watt-hours), not just kW (kWh), in this GUI Window #2: 2. Grid-connected > Advanced Simul. > Output File > Units As I said above in this thread, in general, I'd like the settings of GUI Window #2 to draw from the user-defined settings of GUI Window #1. If you don't want to use W (Wh), then I suggest to remove the option altogether from the PVsyst software program (i.e., from GUI Window #2). Finally, I'm not sure why the unit in GUI Window #2 says "Power" while the unit in GUI Window #1 says "Energy" (I think this confusion led me to make my previous typo). Hope that makes more sense. Thanks again.

Suggest to allow modeling multiple sub-arrays w/ the same orientation. Presently, you get the error "The orientation X is redundant. Do you want to delete it?" Would eventually like to assign albedos (#1) and shading scenes (#2) to different sub-arrays, even if those sub-arrays have the same orientation. I've already added posts to the PVsyst Forum requesting these two (#1 & #2) features.

Would like the option to model multiple albedos for a given project (rather than the existing, project's global implementation). Not sure how to best implement this; perhaps associated w/ each sub-array. I'll follow up if I think of any other ideas. Thanks.

Following up on this. ~1-min. is not enough time to make important edits to our PVsyst Forum posts. Thanks.

It is reported in literature [1] that the p50 (median) derived from a Monte Carlo- or convolution-based uncertainty analysis [2] is more appropriate to use (and not always the same) as the primary AC energy into grid value (E_Grid simul) that comes out of PVsyst. e.g., Not all the distributions that feed into the Monte Carlo are normal Gaussian distributions (e.g., the Gamma-shaped degradation rate distribution from Dirk Jordan [2]-[3]). Does the p50 in the PVsyst p50 estimation directly use E_Grid simul? Or is the p50 derived from the uncertainty analysis? Is it really a median p50 (or is it simply E_Grid simul)? [1] https://www.researchgate.net/publication/318259323_A_Framework_to_Calculate_Uncertainties_for_Lifetime_Energy_Yield_Predictions_of_PV_Systems/ [2] https://www.eupvsec-proceedings.com/proceedings?paper=19917/ [3] https://onlinelibrary.wiley.com/doi/10.1002/pip.3566/

PVsyst > Settings > Preferences > Default values Would like the option to set Energy units to Watts & Power units to Watts here in this window Would also like to be able to specify the default date format here in this same Preferences GUI window (e.g., DD/MM/YY vs. MM/DD/YY) -> Same set of date options as in the "Definitions for ASCII output file" GUI window Basically, it'd be nice if we could define our preferred options for the ASCII output file under this Settings\Preferences window. Then the ASCII definitions window references (obtains settings from) these selections in the Preferences window. Hope this makes sense. Thanks!

FYI only, the geographical site definition GUI (PVsyst > Databases > Geographical sites > New > Geographical Coordinates > Country) has BOTH USA and United States.

FYI only, I noticed that some of the PVsyst input data folders are missing from the main file directory Help Menu page: https://www.pvsyst.com/help/file_workspace.htm Namely, - ComposePV\Clients (is NOT presently documented elsewhere in Help) - UserBatch (IS documented elsewhere in Help) - UserHourly (IS documented elsewhere in Help) - UserHourlyParams (IS documented elsewhere in Help) - UserImages (is NOT presently documented anywhere in Help) - UserOptimization (is NOT presently documented anywhere in Help) - UserRecycleBin (IS documented elsewhere in Help) Recently, I had to import *.GIM & *.JPG files, & I wasn't sure where to put them. I checked the Help Menu & couldn't find any associated documentation (in this case, of the UserImages folder).

I agree w/ @johank that it would help to have the .SIT file included in the exported project .zip. If the .SIT is modified w/in the project, then perhaps that can take a different filename extension (.SIF, .SITm, .SITx, etc.). e.g., When I want to import Measured Data for a given project (a posteriori), I want to use the same .SIT file as used in the pro forma (a priori) PVsyst simulation. Having to manually recreate this .SIT file (b/c it does not appear in the database) introduces the possibility of user error.

Thanks. In my original post, I used the PVsyst default, semicolon separator. Indeed, when I switch to the comma separator, it opens properly in Excel. I'm still a little surprised that, when using semicolon, only one single row (Row 6) has data which spills out of Column A into columns B, C, etc. when you open the file in Excel. Namely, I'm surprised the design of Row 6 is this: Existing semicolon design (Row 6): Simulation variant;US-Project_name_carport2_rev07.VCF;13/05/22 14h49;tilt3, pitch50,YL530, unlimited sheds, 1340, bifacial albedo 0.1, rev07; Instead of this (proposed semicolon new design) (Row 6): Simulation variant;US-Project_name_carport2_rev07.VCF;13/05/22 14h49;tilt3;pitch50;YL530;unlimited sheds;1340;bifacial albedo 0.1;rev07; (Note that all I did was replace some of the commas with semicolons & eliminate some spaces.) In the proposed semicolon new design, everything works well. In the existing semicolon design, you get a warning in Excel and data gets overwritten when separating the columns by semicolon.

Steps to reproduce: 1. Export output 8760 .csv file via PVsyst simulation 2. Open in Excel 3. Click "Text to Columns" > Delimited > Semicolon > Finish WARNING MESSAGE: "There's already data here. Do you want to replace it?" This is b/c there is data in Column B. There should only be (delimiter-separated) data in Column A. Please fix this formatting issue in the output 8760 .csv file. Thanks!

@dtarin: Thanks for weighing in on that one point. Here's a reference I found to support your first claim: https://www.pvsyst.com/help/iam_loss.htm

@dtarin: As I wrote above, it works for a limited time after you submit the post (e.g., 1-2 minutes). The previous forum allowed edits indefinitely.

Hi, Are there any plans to include rear-side IAM, soiling, or spectral adjustments in calculating global plane-of-array POA effective irradiance on the rear side of bifacial PV modules (in addition to the existing near shadings for rear-side global POA incident irradiance already taken into account within the PVsyst bifacial view factor model)? Regarding the latter (spectral), reportedly there are bifacial CdTe PV modules in development & coming soon to the market. P.S. I need to check the PVsyst Help Menu on whether far shadings are already taken into account (for rear-side Global POA Incident Irradiance); if not, I'd like to add this to my above question.

P.S. In addition to the removal of structural shading factor SSF in the above example, and in the context of trying to use the existing PVsyst to simulate pyranometers' or reference cells' measured irradiance at one or more given point location(s) in the array, I am also wondering about the "Height above ground" input for Bifacial systems. Namely, do you simulate a different one when trying to determine the correct GlobBak to match the measured case of a rear-facing pyranometer/reference cell in the field at a given vertical (ignoring horizontal, e.g., edge effects for now) point location in the array? Are there other PVsyst inputs besides SSF and Height Above Ground to consider in the context of performing apples-to-apples, regression-based Measured vs. Modeled Power capacity tests (essentially comparing the Pmes vs. Gmes VS. Pmod vs. Gmod correlations)? (I suppose Height Above Ground also matters for front-facing, esp. if there is a row in front of the sensor, so I suppose my previous post already in some sense asked this question, just less explicitly.) Thanks again!

Any updates here? I just tried to edit one of my recent posts. I got an error (see below). And, for more historical posts, there's no option to Edit at all. Again, the previous PVsyst Forum more ideally allowed for continuous editing/improvements with no time constraints. Oops! This content can no longer be edited. It may have been moved or deleted, or too much time may have passed since it was posted for it to be edited.

Hello, Every large-scale project in the USA is commissioned with an ASTM E2848 capacity test. The derived Measured Power is compared to the derived Modeled Power. Global plane-of-array POA irradiance Gpoa is essential to this multiple linear regression-based test. Measured Gpoa needs to be comparable to Modeled Gpoa (apples-to-apples). Measured Gpoa (front-side facing): Sometimes installed entirely unshaded Sometimes installed on the (vertical) bottom of the frontmost array Sometimes installed on the (vertical) bottom of an array shaded by the row in front Sometimes installed on the (vertical) top of the frontmost array Sometimes installed on the (vertical) top of an array shaded by the row in front Sometimes installed in the (vertical) middle of the frontmost array Sometimes installed in the (vertical) middle of an array shaded by the row in front Sometimes installed on the (horizontal) edge of the frontmost array Sometimes installed on the (horizontal) edge of an array shaded by the row in front Sometimes installed in the (horizontal) middle of the frontmost array Sometimes installed in the (horizontal) middle of an array shaded by the row in front Sometimes installed at a fixed tilt Sometimes installed on a tracker (tracking) Sometimes measured with pyranometer(s) Sometimes measured with reference cell(s) Measured Global POA (rear-side facing): Same options as above except rear-side facing Replace "frontmost" with "rearmost" What is the comparable Modeled Gpoa to use for each of the above scenarios? For example, for rear-side Gpoa that is entirely unshaded, do we have to run a separate simulation w/ the structural shading loss factor removed? My suggestion is this: Allow us to simulate the measured front- and rear-side global POA effective and incident irradiances at specific (user-specified) point locations in the array for the purposes of running the capacity test. Report it as separate columns of PVsyst other than the typical GlobEff, GlobInc, & GlobBak (e.g., Geff_SimMes, Ginc_SimMes, Geff_SimMesBak, & Ginc_SimMesBak). Other options than "_SimMes": _MesPt, _PtMes, _Sensor, etc. Finally, sometimes one or more pyranometer(s) is used for measurements; other times, one or more reference cell(s) is used. So, I think it’s important to simulate both front- and rear-side global POA effective and incident irradiances, respectively, at the given user-specified (front- & rear-side facing) locations in the array. Thanks.

Upon reducing Grid AC Power Limitation applied at POI (-9.27%), these changed by the following relative amounts: BkVFLss: -0.01% IL_Oper: -0.1% IL_Pmax: -0.01% EArray: -1.11% Plus changes to several losses after the inverter. Would you please comment on EArray? Thanks again.

Thanks for your quick reply. 1. Unfortunately, I cannot share the models, b/c the project details are proprietary. 2. I'm curious if the four model outputs I listed are expected to change (in theory) as a result of the one (single) changed model input that I described. 3. If I have time (no guarantee), I'll see if I can reproduce it using the PVsyst Demo bifacial model. In the meantime, please feel free to do the same exercise, especially if the answer to #2 is "No".