jammyc

It would be helpful to be able to see the nominal system voltage and design current determined by user-defined multiplicative safety factors to Voc,stc and Isc,stc. This would have no "physical" implication to the model, but would be a useful guide during selection, similar to the estimated operating conditions. For example, system components may be defined by U=1,2xVoc(stc), irrespective of site conditions. The safety factors would be defined on a per project basis from a default, as different locales have different requirements. I have recently seen a site where the developer neglected to consider design factors per IEC 60364 because it didn't flag here, which made BOS design a little tricky. Yes there are workarounds but it's easily avoidable.

There might not be many meteo data sources, but load metering data are often in half-hourly or higher resolution.

Thanks but that doesn't quite achieve the objective which would be to tabulate / compare the inputs, especially if those inputs aren't available for modification in batch mode. I was primarily considering it as a "pre-flight check" before initiating simulations, issuing reports etc.

I have just used the compare reports tool and found it very helpful. I wonder if a similar tool could be used to tabulate variants in a project with user-determined columns. This could be both inputs and outputs. This would allow quick sense-checking of, for example, consistency of input parameters between variants particularly when maintaining several "live" options in parallel. For example, "have we set the DC ohmic loss correctly for each variant". There are of course a lot of parameters so the user would have to select which to show, and perhaps only summaries could be provided for some sections such as providing total DC and AC rating of a system with multiple subarrays. Obviously this can be done "manually", looking at each report in turn, but is time-consuming and hence error-prone. It would of course also be helpful when producing reports for clients.

Hi Andre, Thanks for the advice earlier in the week; eventually got things working. 1) Please can you expand on the issue with "zero-export" (grid export limit = 1kVA) sites. Do you know why it occurs, and what the trigger points in the design are? 2) I have noticed that, for grid connected PV with storage in self-consumption mode, the parasitic auxiliary losses (e.g. night losses) are recorded in different places to simple grid-connected sites. This means that E_grid and E_Solar are not directly comparable.

If, for some reason, you're not using the values set out in a local standard, then selecting the Tmin is indeed a task in itself, and would in my view need to be justified considering all available data plus a reasonable (there's that engineering judgement again) headroom depending on the quality and quantity of that data (thirty years of hourly data from a meteo station a mile away in uniform terrain is rather different to a synthesised TMY monthly from a satellite). You could as part of this go back to basics and model the actual array voltage over the time series of data that you have, your specific design etc with an allowance for manufacturer tolerance. I'm assuming you're a designer; While you might be happy to keep that internally during initial sizing, at some point I would advise that it is specifically agreed with the client and also the equipment suppliers as warranties / performance guarantees will likely be at stake.

Hi Andre, thanks for getting back. Do you mean there are general problems with zero-export sites? That's a major limitation on a common design requirement... Can you expand on this / is it documented anywhere? There are several options in the application that appear to specifically provide for this Just one homogenous sub-array in this case. Understood, but... for the avoidance of further confusion, in either case which output parameter should I use to determine the solar energy supplied to the user, including any storage? E_Solar? Is this accurate or does it affect inverter operation during curtailment?

Might this be one for the Suggestions section? I agree it would be handy for modelling historic parks. Of course, if you know the specific arrangement and depending on what it is you are doing you might be able to recreate an equivalent module for that project, as seen by the inverter.

This is often covered by national standards or national annexes to international standards. From memory (a few years ago so might be wrong), the AS/NZS for PV system design specifically references design temperatures. Beyond that is a matter of contract and engineering judgement.

I see, that wasn't my understanding from the documentation. Thanks for clarifying. It would be really handy to be able to do what I was suggesting for large plants.

Just to add: The systems do have a heavy DC/AC ratio, but not ridiculously so, and the IL_PMax is less than the inverter rating (even allowing for power factor).

Hi, I am comparing a grid connected system feeding an existing load with zero export to one with an additional small storage, and am getting an unrealistic increase in ESolar in the latter. For the solar-only option, the scheme is defined with a self-consumption defined from a CSV and scaled. A 1kW grid limit is applied (for some reason this cannot be set to zero), specified in active power (the system runs at 0.95PF) at the injection point. For the storage option, the strategy is set to self-consumption, with the same scaled CSV. Allow to export to the grid is unchecked. I have to deselect the grid limit in Energy Management for the simulation to work. All other parameters are the same. When I run them, the annual ESolar with storage seems to be far too high given the storage capacity relative to the array. Looking at the hourly figures, for some reason the array stops generating with losses shunting to IL_PMax at certain times (even though it's below the inverter rated capacity) for the non-BESS but in the storage scenario it continues to generate. Any ideas what's going on?

Similar to (and extending) the batch mode but allowing different variants, projects and simulation configurations to be queued to later execution. For example, if we have several batches to run (say, south facing, east-west and tracking for the same site, with and without storage), each taking a few hours, at present we can set one running but have to wait for completion before the next can be configured. If someone is not present this is of course dead time. If we could queue batches during the day to run unsupervised overnight it would be a substantial time-saver. Alternatively, allowing multiple instances of PVsyst to run in parallel without creating file access clashes would at least mean we can start work on the next run while the first processes.

You can include the ground in the simulation by selecting the ground object and selecting the "Enable shadow casting" checkbox.

Hi, I am trying to use the parital shading calculation tool for the first time. I have put roughly a third of the tables in my scene (imported from Helios3D) into the Partial Shadings Selection group, and the system definition matches this group. However I now can't run the scenario because the area of the 3D fields is far larger than the area of the modules defined in the subarrays. I note in previous forum posts that the tables should change colour when they're put in the group but I've not noticed that happening. Any suggestions?

No worries. I suspect, but might be wrong (I've not tested properly), that it is related to having "Start from different VCi base files" selected (which I had enabled but didn't end up using (all set to the same value)).

Hi, Workflow: Create baseline project / variant -> Set up batch mode -> Open CSV file & edit runs -> Run batch -> Decide to add different input values -> Edit CSV file -> Open batch mode -> Select existing CSV... CSV file, which was several thousand lines, is now only a few hundred, and appears to be curtailed midway through a line. If, on the other hand, I open batch mode -> Select existing CSV -> THEN edit the CSV before hitting Run, then it works. This has caught me several times, as it seems fine but finishes early!

Ahah! I think the issue was that I had Grid Power Limitation active in Energy Management (from the simple non-storage option)... Deselecting this, but deselecting the "Allows solar injection into the grid" mode in Storage -> Self-consumption appears to make things work as expected.

Sorry, my bad at the end of long day, yes I meant SOC.

Hi all, I have probably got something misconfigured so apologies. I am trying to model a grid-connected system with an existing load where the PV->Load takes priority, then any excess solar production goes to a battery which can then feed the load when the PV can no longer meet it; a grid import is available when neither battery not PV can provide. The load is relatively consistent through the year so the base (no-storage) scenario has a large amount of spillage in Summer. For economic reasons it is expected that the storage facility rating is likely to only be ca. 10-50% of the array rating for a few hours (of course determining those ratios is the task in hand!) I thought that was the intended function of the "Self-consumption with storage" mode. In the test model I have set up, I would have expected it to do nothing in winter months, then in the summer to jump from 2% DOD to 98% DOD as soon as the load is exceeded, and reversing afterward. However, for some reason when running the model, the battery discharges in the first few hours (which is presumably the starting DOD), then sits at the minimum DOD for the rest of the year. Why isn't it charging? What am I doing wrong?! Thanks in advance...

Hi Hizir, Thanks for the response. For various reasons I've only just had chance to have a quick play with a test project, but if I understand correctly, in batch mode: Installation costs: Anything listed under "PV modules" is scaled by the qty of modules, regardless of module STC rating Anything listed under "Inverters" is scaled by the qty of inverters, regardless of inverter rating (etc) Everything else (other components, studies etc) is fixed and does not change for the entire batch Operating costs: All OPEX is fixed It looks like the quantity for inverters and module sub-costs is automatically adjusted to be equal to the inverter and module count even for the rows that are not greyed out?

Hi, Two part question: 1) How does PVsyst update costs if the project parameters (e.g. qty or size of modules) subsequently changes? Does PVsyst "remember" whether a cost was input as XX absolute, XX/Wp or XX/m²? What about if I define a custom cost item? 2) Is this also applied due to changes in batch mode, or are they lumped somewhere? Spurious example, it is convenient to input the grid connection costs as a fixed XX, inverter price as X/unit, but module price as X/Wp. If I then change both the qty inverters and qty modules in batch mode, will the costs change as I expect? I have historically carried out the economic evaluation as a post-simulation process, so apologies if this is obvious and I've missed it. Thanks in advance

I have just recieved the attached from PVsyst (credit to them for replying within the hour!) Hope that helps anyone else having the same.

I have just installed v6.2.9 and am having the same issue

+1 from me It would be very helpful in anaylsis of measured data In many jurisdictions billing is half-hourly basis It would help with analysis where loads change frequently Multiple meteo data sources provide sub-hourly inputs and it's a shame to throw that out! ...etc