[NEMO-devel] scenarios.re100_batteries(c)

[Don Cameron]

Hi Ben,

Thanks for the guidance.

I should mention that in my own modelling I have had occasion to wish that I could plot a curve with 8760 points on it. Understanding nemo should help me to do that. I am looking forward to acquiring that understanding.

There are no mistakes in the Notebook. There is the one anomaly that I mentioned in another email about "%matplotlib inline" that is an artifact of running in Pycharm and not in IPython. I think that is worth mentioning in the Notebook. Nemo runs in Python3 but was it started using Python2?

I think it is also worth specifying when a user needs to use the evolve script to get useful results. A reference to documentation that describes the cost optimization algorithm would be useful too.

I will fetch the trace files from the Canberra server and access them locally by replacing the web reference in the config file to a local path reference.

I can then step through the OCGT/CCGT scenario to understand the mechanics of the nemo code.

I will also use the evolve script to run the re100_batteries scenario. I need to understand the storage capacity provisioning rules documented by Blakers, Lu, and Stocks in their paper.

Regards,
Don

________________________________
From: Ben Elliston <bje at air.net.au>
Sent: December 13, 2019 9:01 PM
To: Don Cameron <dcameron3009 at hotmail.com>
Cc: nemo-devel at lists.ozlabs.org <nemo-devel at lists.ozlabs.org>
Subject: Re: [NEMO-devel] scenarios.re100_batteries(c)

Hi Don

Welcome and thanks for your introduction.

> I loaded nemo in Pycharm that is running Python 3 and tried out the
> sample code on the Jupyter Notebook page. I had to put() around the
> argument to the print command.

Were there any mistakes in the notebook that you found?

> One of the lines is
> print(c.generators).
> All of the solar and wind resources are 0kW. The hydro resources had
> positive capacity values.

OK, so a bit of background is helpful here. The default scenario was
originally the only scenario before NEMO even had a name. It provides
meaningful capacites for the various types of generators so that you
can set up a context object and then run nemo.run(c). You will then
get meaningful results.

However, most of the scenarios are never run by hand this way and are
always cost-optimised using the evolve script. For this reason, when
writing a scenario function, I was usually lazy and would specify zero
as the capacity of most generators (except when defining specific
legacy generators with fixed capacities, like Australia's various
pumped hydro systems).

If you just want to play around with one scenario, the "ccgt" is a
good start. It simulates one mammoth CCGT and one mammoth OCGT.

> I did a bit of stepping through the code in the debugger but I think
> that probably triggered web request timeouts. So I would have to
> think through a bit more on how to breakpoint the code to avoid the
> timeouts.

NEMO fetches all of the trace data from a web server in Canberra. This
is convenient in some ways, but inconvenient in others. You will find
it helpful to fetch them all and save them to disk. Then you can
modify the entries in the "generation" section of the nemo.cfg
configuration file to refer to local filenames. This will (a) speed
things up and (b) likely overcome the problem you described when
stepping inside the debugger.

Happy to help with anything that is missing, confusing or could be
improved. Feedback is most welcome.

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/nemo-devel/attachments/20191214/8ae9d764/attachment-0001.htm>