Closed alonsopg closed 6 years ago
A brand-new implementation of the server would be a tall order. The only way I could see that would not require a major implementation push would be to use jython to implement individual modules. If you want to try implementing a customer model under jython, I would be interested to see how it goes. It should also be possible to implement broker modules this way -- that might be quicker and easier to start.
Could you be more specific about which libraries you think would be useful?
Yeah, I understand its basically a reimplementation of the server. But libraries it would be interesting to experiment with libraries like keras and tensorflow.
It's been a while since I did a careful performance analysis of python. The last time I checked there was a significant penalty over Java. Here's a benchmark set that indicates it could be a problem. The server typically uses a little under 5% of each 5-second timeslot for its processing, leaving the rest for brokers. Of course brokers don't necessarily have to wait for the server, but there are some tasks that benefit from having data from the server for the current timeslot to make decisions about the following timeslot. I assume the libraries you are interested in are based on C implementations, which would make them unusable in jython. This is the case with tensorflow.
Another option would be to implement models that run in a separate process. This should not be difficult -- I made a version of the broker framework that works that way for R, but so far nobody has taken it up to try to build a full sample broker with it. It's in the broker-adapter module if you want to take a look, along with a basic R process that uses it. It should not be hard to adapt this to python.
To make this work with server modules, you might have to define a few more message types to handle bits of the server API that the broker doesn't see, but beyond that I think it could be done. Are you volunteering to do this?
FYI There's also a Java API for Tensorflow : https://www.tensorflow.org/install/install_java
Although the java environment looks a good tool for building the server, I personally think that the competition must allow everyone (no matter the programming language) to participate. For example, there are shared tasks that use evaluation services as this one, that let evaluate and replicate competitions no matter which programming language the participants decided to use for the competition.
I agree that it would be desirable to make the competition agnostic to programming language, at least on the broker side. That's one of the reasons we chose Apache Active MQ and XStream for the communication infrastructure, and it's why I put together the broker-adapter example. I see no insurmountable barrier to doing the same thing with customer or genco models. It might be possible to make the tira approach work for the Power TAC problem domain, but at this point I don't see that tira actually addresses the competition aspect as effectively as the direct-competition model implemented in Power TAC. I also don't see anyone volunteering to make it happen. I am at the limit of my capacity already, and I suspect Govert and Erik are as well. We would be very happy to welcome new volunteers to the team.
I'm going to close this for now, since what remains seems to be a duplicate of #859. The broker-adapter and the R-language adapter should be enough to help a Python developer get started on a Python broker.
Is there any plans to provide an Python power tac server? There are some interesting libraries that are just available for Python programming language.