Hi, I am trying to model the UK’s energy market for 2023 within AMIRIS, it is in the context of a research paper I am doing for my masters project with the University of Sheffield. I am new to Java and AMIRIS and am trying to get my head around it. I have set up csv files with data from the UK over 2023, and have just tried to run AMIRIS using eclipse-workspace, and it has returned this error:
java.lang.RuntimeException: List has not exactly one entry!
at de.dlr.gitlab.fame.communication.CommUtils.ensureExactlyOneEntry(CommUtils.java:41)
at de.dlr.gitlab.fame.communication.CommUtils.getExactlyOneEntry(CommUtils.java:32)
at agents.trader.renewable.AggregatorTrader.sendYieldPotentials(AggregatorTrader.java:279)
at de.dlr.gitlab.fame.agent.Agent.executeAction(Agent.java:104)
at de.dlr.gitlab.fame.agent.Agent.executeActions(Agent.java:87)
at de.dlr.gitlab.fame.service.Scheduler.scheduleNext(Scheduler.java:80)
at de.dlr.gitlab.fame.service.Simulator.proceedWithSchedule(Simulator.java:125)
at de.dlr.gitlab.fame.service.Simulator.run(Simulator.java:103)
at de.dlr.gitlab.fame.setup.FameRunner.run(FameRunner.java:45)
at picocli.CommandLine.executeUserObject(CommandLine.java:1939)
at picocli.CommandLine.access$1300(CommandLine.java:145)
at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2352)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2346)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2311)
at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
at picocli.CommandLine.execute(CommandLine.java:2078)
at de.dlr.gitlab.fame.setup.FameRunner.main(FameRunner.java:34)
Could someone give me a bit of an insight into what I have done wrong, and where I can find out where the extra entry is, currently I am struggling to work out if it is in a csv or pb file and if so then which one it is in.
Thanks for any help 
It seems to be something to do with the aggregate trader, and the yield potential within the support for renewables policy, but not really sure where to look to try to fix this?
Dear Ben,
it’s great to hear you are using AMIRIS. Sorry for the late response — we were on Easter holidays.
Regarding your error report — I guess the message could be more explicit. However, I have a guess what went wrong: Did you maybe introduce multiple SupportPolicy agents or add a contract copy of YieldPotential-contract. Or did you maybe add another DayAheadMarket (or copy its GateClosureInfo-contract)?
The AggregatorTrader cannot communicate with multiple DayAheadMarkets or SupportPolicies at the same time, thus the error.
If you are unsure, I can offer to have a look at your scenario.yaml or contracts files.
Kind regards
Christoph
Hi Christoph,
Turns out it was just an error that I had made when I was changing the .yaml file from the germany case study to a UK case study.
I have it running fine now, and am trying to run some future scenarios with a high percentage of variable renewable energy, and large amounts of storage. I am just having an issue with the storage trader, it seems that it will only discharge a certain percentage of capacity each hour to try to help meet demand. This means that at some hours, demand is not being met completely, and therefore the price is at the value of lost load, however there is still energy in storage. Is the model saving this storage to ensure that the non-sheddable baseline demand is met, or is the storage operator only allowed to discharge a certain percentage of capacity each hour?
Thanks for any help, and thanks for the help on my past question
Kind regards,
Ben.
Hi Ben,
storage operation depends on its employed StrategistType. If you use:
SINGLE_AGENT_MAX_PROFIT: the strategist tries to optimise its profits. This includes withholding power in case of scarcity to keep prices high.SINGLE_AGENT_MIN_SYSTEM_COST: the strategist minimises system cost. This should avoid scarcity events - if possible. In case your scarcity is unavoidable due to low supply, scarcity can happen even if the storage is not yet empty - as it does not matter to the storage when exactly the scarcity occurs…
If you are using the latter strategist: Can you confirm that the scarcity is unavoidable, or does the scarcity occur even if it could be avoided?
I am using the latter strategist currently, I believe the scarcity is occurring even if it could be avoided ? The storage seems to have enough stored energy to meet the demand if it released it all on the hour, however it holds some of it and only releases a small proportion each hour?
I presumed that even if the scarcity is unavoidable, the storage would empty to at least cover as much as it can? Maybe I’ve misunderstood how the storage trader operates ?
Hey Ben,
SINGLE_AGENT_MIN_SYSTEM_COST should behave like so:
- if enough energy can be stored to avoid scarcity for all hours of the forecast horizon (
ForecastPeriodInHours), it should avoid scarcity consistently.
- if not enough energy can be stored to avoid scarcity in all hours of the forecast horizon, scarcity can occur in any of these hours - earlier events will not be prioritised.
If you can confirm that this behaviour is not achieved: Could you write a bug report at dlr-ve / esy / AMIRIS / AMIRIS · GitLab?