MNWild

Following

Is module area the area with user entered frame, or user entered inactive bands, without? Or is the area based on dimensions in .pan file? Is it supposed to be cell area etc?

Instead of throwing a cryptic error, may I courteously propose the software spits out a dialog box that contains all those words from your June7 response?

Bothersome phenomonon indeed. Wish I didn't have to work around this and trick clients or claim pvsyst doesn't let us type in the correct values. Either your GCR will read wrong (not equal to module datasheet length/pitch), or your backtracking limit angle will be wrong, or your sensitive area, or your actual 3d scene module width or length idk which. It's very inconsistent. Inactive Band Left Right, Inactive Band Top Bottom, bandwidth X spacing, Y spacing Frame L/R T/B Backtracking Limit angle, GCR, and bifacial section's version of above conflicts on report batch version of above We have to parameterize all this information and test every revision to understand what pvsyst thinks it's doing, vs what it says it's doing, vs what help file says its supposed to do, vs what is on report, vs what forums answers say, vs orientation tab, vs 3d scene, vs bifacial page. All definitions overlap and change depending on if you are in shading scene or elsewhere in program.

For trackers it doesn't equate to logical sense. X axis in shade scene is east west. But a single axis tracker's "X spacing" will actual spread the modules further apart in the Y direction along length of tracker which is the "Y axis in shade scene". Typing a value in the "Y spacing" of .02m or 10m doesn't appear to do anything to the tracker dimension because the modules are 1 in portrait along single axis tracker n/s. **1 in portrait I should clarify further even: meaning industry standard description of the long side of module set E/W and module short width is N/S...pvsyst may or may not have "portrait or landscape" label correct in 3d scene for 1-axis trackers depending on the version you're using. So you have to sanity check all the visuals and measure stuff until you get fired for taking so long to model a solar site.

This has been a problem for years. Looks like in in the release notes from 7.x.18 the latest release they actual fixed the ability export the .met finally. But not .sit. So the export project function is useless and confusing. Also, Does software still not export the shade scene as well? We've been manually hunting and pecking to compile all files for sharing with outside entities.

Let's say I wanted obtain a more accurate value for actual inverter setpoints in 8760(closer to reality): 1st: Would I have to run PVsyst once with default(non-separated) grid limitation setting to get cleaner* 8760 of inverter output set points. 2nd: Then run PVsyst 2nd time: selecting the grid limit setting to "account as separate loss". Then Pull this separated clipping "loss" from 8760. 3rd step: Would I subtract the 2nd step's "separated clipping loss" in 8760 from the 1st step's Inverter Output 8760? Is there a method to avoid two models? *I deduced above because you stated the default grid limit settings(non-separated) 8760 will contain clipping "losses" inside "overload loss" 8760 field...But that 8760 field "overload loss" contains other losses. So a user can't simply subtract "Overload Loss" 8760 from the inverter output 8760 field to obtain inverter set-point closer to real world? Note: I forget the sign convention off top of my head for these 8760 fields, but let's assume everything is positive: clipping losses and inverter output. Example so when I say subtracting I mean: 121MWinverter output - 20mw Clip will get us to 101MW inverter set point.

What great news on Valentine's day. Wonderful to hear.

thumbs up emoji

+1. Nearly impossible to review and compare what a user enters vs what's shown in PVsyst. We never know if the black box is propagating a rounded value or a magical unseen entered digit exists. Makes for more meetings too.

+1

?

+1, thanks for sharing issue. I would have thought PVsyst would separate xfmr loss and ac loss with independent Bases especially since the new transformer section allows user to type in a kVA rating. This applies to MV and HV tranformer "Nominal Power" under Datasheets section. Also, if your transformer nominal power typed in is too large PVsyst will error as well. Example xfmr is 8000kva and inverter nom is 3000 from .ond. "HV transfo: The Transformer nominal power is far higher than the maximum output power of the inverter, i.e. Future Development Request: AC loss section & new MV cable section to provide similar flexibility similar to the new transformer section appears to have in v7. Allow user to type in custom base rating and type in %ac ohmic or kw cable loss instead of forced into a base of Pac(stc)=Pdc(stc)*(efficiency).

Looks like PVsyst just released a 64bit version. Trying figure out how to download but I thought I would respond to this thread. In version 7.0 (25.05.2020) 5.25.2020 May 25th. New features: Support of 64-bit architectures : this will extend PVsyst capabilities of handling large projects and shading scenes Irradiance: new improved treatment of the circumsolar component, impacts on the electrical shadings and vertical Bi-facial systems System : unlimited number of sub-arrays Shadings : conversion of fixed tables to trackers, new trackers with central gap parameter for bifacial, import of trackers from Helios3D, import of PVC files Output AC circuit : definition of several MV and HV transformers, with their specifications Live results display : see results values and graphs while the simulation is running Economic evaluation : Levelized Cost of Energy (LCOE), Net Present Value (NPV), multiple loans of multiple types, advanced depreciation configuration Economic evaluation : now available for Stand-alone and Pumping systems Simulation : display of warnings during the simulation and with the results Improvements: Module Layout: great improvements in submodule shading calculations accuracy, print of the layout has also been improved and can now be printed in the report User interface : improvements of the user interface and user experience License management simplification Localization : full-software translation coverage (except the Help), Turkish and Korean languages now available

I'll private message a work around I've used. I wish I would have read this sooner since some time has past now.

Hi MarcoMalagnino, Curious what exact efficiency number is used internally to PVsyst to calculate Pac(stc)=Pdc(stc)*(euro efficiency) ? You stated it's the euro efficiency, is it a specific one, or is it dynamic? I ask because there are 3 different voltage levels for efficiency in ond and I've tried to figure out which efficiency is used by backing into from the existing 8760 loss calculation, but no luck. Yes, this exact AC loss problem especially for transformers has been on my radar as well for many years now. I even sent a study to PVsyst folks to illustrate issue, showing how if a user types in a percentage ac loss the no load loss are increasingly overestimated and load losses are increasingly underestimated as the dc/ac ratio of the project goes up. All because of exactly what you stated, Pac(stc)=Pdc(STC)*some efficiency is used for the ac base for calculating actual KWac losses instead of correctly using point of interconnect as the base or the inverter limitation at terminals as the base. The only workaround I have is post processing ac losses which is cumbersome but required many times since it puts large utility projects at risk $millions of dollars to pass a performance test if AC losses aren't modeled more accurately. You can trick PVsyst as an alternative but then everyone involved will ask why the input % Load losses in PVsyst is higher than actual or will ask why the input % no load loss is low and doesn't match design. My theory is that the ac loss section was programmed initially with typical designs 8-10 years ago which had dc/ac ratio's of 1.0, PVsyst used that as a "reasonable assumption", but no longer is this accurate and the logic has been forgotton.

I agree. It would be a great thing. But first I have to figure out how to get this damn batch to simply take 11 Existing variants, run them, export pdf/8760. Seems like it's more work to setup batch than just manually clicking 50k times the normal way.

Agreed. Right now, the number of clicks to create these never-used .sit files and rename .met files is just wonderfully confusing...and then you realize you named the filename different than the description and can't find it later. These .sit files aren't even exported when exporting projects to boot.

Yes, it would be useful.

+1 For an explanation. Or a warning not to check the new box that gives more energy for free. At least a single sentence, slightly vague, release note to tease us but leave us with more questions, only joking. Best wishes to all p.s. Request to also include a nice short video with each software release note to illustrate, visually, confirming what's been changed/why and how to use..and more importantly what old forum/help file information is entirely obsolete.

A colleague of mine posted exact same issues a couple weeks back. Still looking for fix as well.

This is not an Excel issue.