kjs55

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".

PVsyst v7.2.11: The *only* change between the two (bifacial) models is a reduced Grid Power Limitation at the point of interconnection POI (grid injection point). Nothing else changed in the models (carefully confirmed). Differences in losses before the inverter: 1. Observed in exported numeric loss tree: - View Factor for rear side (BkVFLss) loss - Inverter Loss during operation (efficiency) (IL_Oper) - Inverter Loss over nominal inv. power (IL_Pmax) 2. Observed in PDF output report table named "Balances and main results": - Effective energy at the output of the array (EArray) Also, several losses after the inverter (before the grid injection point) changed, which I won't list here unless someone requests it. Thanks.

Just a quick note/small point to say that the number of significant figures for wind speed in the PVsyst 8760 output .csv file is more than expected, e.g.: WindVel, m/s, 0.6, 0.2999, 0.2001, 0.5, 0.5, 0.8999, 0.5, 1.5999, 0.8999, etc.

Hi, It looks like the option to apply a grid power limitation at the inverter level vs. injection point is an EITHER/OR. But, what if we have limits at both the inverter level AND the injection point? It doesn't look like we have the option to apply losses at both points (nodes) in the system (it's only EITHER/OR, not AND). I suggest adding the AND option. Thanks.

Finally, here's the error message that occurs when trying to edit a post after about 1-min. following submission: "This comment 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." Essentially, I'm proposing to please remove the time limit for editing posts, similar to the previous PVsyst Forum setup. Thanks.

This is post is just a test (to try to generate & transcribe the "option to edit has timed out" error message).

P.S. Interestingly, I saw the "Edit" option appear in the ellipsis of my above reply for a brief time following my submission of the reply post. However, that option quickly disappeared after about a minute or so, and now only the options "Report" and "Share" remain in the ellipsis of the reply post (similar to the original post above). Again, I think it'd be very valuable if we can edit our posts over the long term (to add further context & details as we think of it, etc.)!

Thanks so much for your timely & thorough reply - it's very much appreciated. I tried clicking on the ellipsis, however, all I see (as a normal, non-admin user) are the following options: Report and Share. This is why I originally reached out: because I'd expected to see another option for "Edit". Thanks again.

Hi, The previous PVsyst Forum allowed us to edit our posts after submission (for increased clarity, to fix spelling typos, to improve grammar, etc.). Can we do this on the new PVsyst Forum and, if so, how? Thanks. P.S. The previous PVsyst Forum also allowed us to preview our posts prior to submission (to view renderings of special formatting, etc.). Can we do this on the new PVsyst Forum and, if so, how?

Hi, If possible, I'd like the ability to run simulations with monthly AC grid power limitation values (user inputs) instead of one single annual user input value. Thanks.

PVsyst v7.2.10: Many PVsyst users and other PV stakeholders see the bifacial insolation gain in bold font in the PVsyst Sankey diagram and think this is the bifacial gain BG. However, this is incorrect & arguably misleading. A better (DC) estimate of BG is to multiply this insolation gain by the PV module's nominal (or nameplate) bifaciality factor. So, perhaps PVsyst can show this adjusted value on the Sankey diagram and put it in bold font instead. This suggestion is compliments of T. Townsend. Of course, this is still only an estimate of BG, as the true BG comes from running the simulation twice - once for bifacial and once for monofacial (i.e., bifaciality turned off - effectively a bifaciality factor of 0%) - and dividing the energy output metric of interest (e.g., AC energy injected into the grid, E_Grid) of the former simulation by that of the latter. The main suggestion here is to reduce the common misinterpretation of BG that exists due to the design & formatting of the present PVsyst Sankey diagram. Thanks!

PVsyst v7.2.10: How do I assign a particular sub-array shading scene to a particular sub-array that has a particular orientation (azimuth & tilt - fixed or tracking)? Thanks!