Congratulations Jess Kaneshiro, PhD

Last week, my friend Jess Kaneshiro successfully defended his PhD dissertation, "I-III-VI2 (Copper Chalcopyrite-based) Materials for Use in Hybrid Photovoltaic/Photoelectrochemical Water-Splitting Devises". Yes, that's the real title. It might set a record for the most punctuation in a title...(-but-/probably-not).. :)

The talk was interesting not only because it represents a lot of work put in over the years, but also because it was a public offering of knowledge about a source of renewable energy that most people have yet to hear about. Jess studies methodologies and materials that can convert the sun's light energy directly into hydrogen gas. People in the know call this process photo-electrochemical conversion (or PEC) in order to differentiate it from photo-voltaic conversion (PV). PV generation is distinct because it aims to convert the sun's light into electric power (that's the voltaic in photo-voltaic). It's an interesting distinction because the media (and most commercial enterprises) focus solely on PV cells.

The tripping point that I initially had with this research was that the theoretical efficiency of PV cells (the fraction of the sunlight's energy to can be converted into usable electric energy) is higher than the theoretical efficiency of PEC cells (the fraction of the sunlight's energy that can be converted into the chemical energy associated with H2 gas). So then why research PEC at all? I believe the answer lies in the lies---or at least the obfuscations of multiple energy conversions. When a solar cell (either PV or PEC) generates more energy than is needed, we either store or waste that energy. When this happens to a PV cell, we can either send the electric power into a battery (which, by the way, is a form of chemical energy storage), or we could possibly send it "into the grid" so that someone else can use it. The argument for PEC is that if you consider the efficiency "chain" of PV: Sunlight-to-voltage-to-battery (or -to-grid), the end-to-end efficiency is going to be lower than the one-shot PEC conversion: sunlight-to-hydrogen.

This makes some sense to me, but has an obvious shortcoming: batteries are getting more and more efficient all the time, so this argument may in fact break down later on.

Source: J. Kaneshiro, N. Gaillard, R. Rocheleau, E. Miller, Advances in copper-chalcopyrite thin films for solar energy conversion, Solar Energy Materials and Solar Cells, Volume 94, Issue 1, January 2010, Pages 12-16.

Jess's defense outlined another use for PEC power: Why not use it in conjunction with PV cells? Jess's most recent research has been in hybridizing cells to contain both PEC and PV subcells. This appears to hold great promise because each sub-cell can be tuned to capture different segments of the sunlight's spectrum. In effect, they are sequentially picking up the pieces of light that fall through the other sub-cells.

This looks like challenging and real-world-relevant work, and I wish Jess continued success and a bit more media attention for his field!

Stay illuminated,

Clay

Version Control for Paper Writing

Version control is a concept I've come to appreciate more and more recently. Originally, I thought its usefulness was constrained to programming and code writing. Lately, however, I've found it to be indispensable in my paper and document composition.

What's version control?

These days, pretty much everything has a version: movies (Star Wars Episode 1, Star Wars Episode 1 HD, Star Wars Episode 1 3d), your phone (iPhone, iPhone 3G, etc.), your phone's operating system (Android Honeycomb, Android Ice Cream Sandwich, etc.), and so on. Version control is the effort to embrace the fact that what you've done in the past is good, but life moves on, so let's not confuse how you're product is going to evolve.

When you produce different versions of a product, it's often nice to be able to have access to old versions while working on new versions. With physical objects, there's not much to do about this: You have last year's car sitting around, and you want to make improvements to it, so you start stripping things off and pasting other things on.

But with electronic (and/or intellectual) products, it can be a waste of space to keep exact copies of old versions around. Think about it this way: You've written a first edition of a book. It has 10 chapters and it looks great. You've saved all the text and the formatting of the book on your computer in a directory called "First Edition".

Fast forward five years, and your publisher tells you about this cool new thing and that they'd really like a second edition of your book, but with an extra chapter on the end (or...in the middle!). Are you going to copy your whole "First Edition" directory, rename it "Second Edition" and tag on the extra chapter in there? That seems like a waste of space if nothing in the First Edition had changed.

If you employed a version control system to your book writing, you could simply start a new "version" of the book that had the first ten chapters "pointing" towards the First Edition, but then with your new chapter tagged on the end (or wherever it is to go).

How does it apply to document preparation?

You may say to all this, "OK, computer projects get changed all the time, and with open-source licensing, it makes sense to split and track these projects, but when I write a paper/essay/document, I know what's going in it, and no one is going to be branching off my work!"

You are probably right: You don't want people branching your work before it's published. However, there are many more parallel connections to computer program development than you may realize. For example, how many academic papers (or even books) these days are written by a single author? Not many. A version control system is useful even among a few co-authors. Different people can write different (or, heaven forbid, the same) sections and then merge them downstream into a complete draft.

Also, as has been my experience, while the overall topic of a paper rarely changes, the details and sections a very often fluid in the early stages. Instead of writing most of a section, then deciding that you want to go in another direction and deleting what you just wrote, why not create a new "version" of the paper and write about the new discoveries there. This way, if you have to go back, you can look at the old "version" to see what you've already written.

Ok, I'm sold. How do I begin?

Well, that was easy! There are lots of options for version control systems. I haven't tested all (or even most) of them. These ones seem to be popular at the moment:

• git
• SVN (subversion)
• HG (Mercurial)

Out of these, I've used SVN and git. I have to say that I stand wholeheartedly behind git (but that's another post....).

Stay committed,

Clay

New Site, v3.0!

Aloha All!

I hope you're enjoying the redesign of my academic web site.

New features include:

• Fluid layout for optimal viewing on any size screen. (Try it! Resize your browser window and the layout should flip around.)
• This blog's posts are incorporated via RSS and PHP and no longer in a messy iframe.
• New page featuring meeting times and presentation topics for the Game Theory Reading Group.

This version is based on the excellent templates provided by YAMB (Yet Another Mobile Boilerplate). Their code was indispensable in teaching me about fluid design and allowing the whole update process to take a little under two weeks of evenings of work.

I'm also very please to be able to bring you these blog entries in a much more native and natural environment than in the previous version. Many thanks to the good people at SimplePie (also on GitHub) for an excellent PHP class that pulls the RSS feed from Blogger and lets me display it the way I want it. As they say, they really do put the "simple back in Really Simple Syndication." Their product is well-documented, and they offer copious use examples. I felt it was a great introduction to PHP programming.

One final shout-out goes to Martin Monperrus for his handy bibtexbrowser PHP script. This tool is what I'm using to generate and display the list of papers we are considering presenting to the Game Theory Reading Group.

One final announcement is that the page itself has moved (sub)domains! The site formerly found on www2.hawaii.edu is now living on ee.hawaii.edu. The move was necessitated by the current version's extensive use of PHP (which the University of Hawaii domain does not support, but the Electrical Engineering subdomain does). So, apologies to all you book-markers out there, but I've put a 301 redirect on the old site, so you should be able to find your way over here.

Enjoy, and please let me know if you have any feedback.

Stay 200 OK,

Clay

De Morgan's Laws in Action

Augustus De Morgan, originally uploaded by Mike Lynch.

Logic: It's a beautiful thing. It's not everyday, however, that I get to implement it so explicitly as I did today.

One of the hallmarks of mathematical logic are some rules set out by Augustus De Morgan called, appropriately, De Morgan's Laws. They go something like this: Take two (or more) statements A and B. These can be things like "The sky is blue" and "We are on Earth." These statements have complements, namely, "The sky is not blue" and "We are not on Earth."

De Morgan gives an equivalence between the relation of these statements' complements and the complement of the relation of these statements. In (better) English, we could say that the complement of A and B is the complement of A or the complement of B. So, in our example, De Morgan tells us that the complement of "The sky is blue AND we are on Earth" is the same thing as saying "The sky is not blue OR we are not on Earth." Confused? Try out the formal statements for a bit of clarification:

where we read "c" as complement,

and

Why would this ever arise in practice, you might ask? In fact, just today I wanted to add a stopping condition to a WHILE loop I had in a program. A WHILE loop runs (loops) for as long as a given statement is true. My loop ran for as long as the variable called FLAG was true. Essentially, I wanted to cheat a little and add a different stopping criterion that would bounce out of the loop if a different variable hadn't been changing for a while.

So in my head, the loop should run while FLAG was true, and it should stop when COUNTER was bigger than 20 and W(COUNTER)==W(COUNTER-20). But, just my luck, you can't really tell a WHILE loop when not to run, you have to tell it when it has to run. But guess, what? These conditions are complements! Enter De Morgan.

My situation was that I want to stop the loop when

is true. Which means that I want to NOT stop (i.e. run) when

is true.

Bonus! We get to use both flavors of De Morgan. First apply the first equation from up top, then apply the second to the B parentheses. After all is said and complemented, I want to run my WHILE loop while FLAG is true AND (COUNTER is less than 20 OR W(COUNTER)~=W(COUNTER-20)). Cool huh?

Stay Logical.

Smarter Grids

Low Mill, Caton, Near Lancaster, Lancashire, UK, originally uploaded by Ministry.

[For those looking for "How to Peak Around a Corner," give me a couple more days. It's a bit harder than I first thought.]

I literally just got out of a seminar given by Marija Ilic, of Carnegie Mellon, on her work and prognostications for making the delivery of electric power more efficient. I was expecting the typical drab droning that usually confronts me from invited speakers, but I was able to pull several salient and cogent points out of her talk. This is a fairly extemporaneous post, so please forgive my stream-of-consciousness style.

Utility companies, in general, try to provide uninterrupted service at minimal cost to their subscribers. We could go on and on about the scruples of utility companies and their guaranteed monopolies, but that is not really very productive at this point, so let us take their cost-minimization desires as a given. While "minimal cost to subscribers" is a very soft term, I never realized how hard the uninterrupted service constraint really was. Imagine this scenario: Town X has a daily power consumption of no more than 90 MW for 350 days a year. Given this information, constructing a 100 MW power plant to supply Town X seems like a good idea. However, for 15 days per year, Town X demands 120 MW (due to heat waves, cold snaps, etc.). If the utility company really had only constructed a 100 MW power plant, all of the directors would be fired after the first year because they couldn't supply the town sufficiently for 4% of the year. So instead, the utility has to lay out the cash to build more power generation capacity that just sits around for up to 350 days a year.

As Prof. Ilic stated, "cost management is all about the spikes." She was referring to the spikes---hourly, daily, and yearly---in demand that utility companies see. If it weren't for the spikes in demand, the total demand would have far less variance, and less superfluous generation capacity would be necessary.

What can we do about these spikes? This is where the system intelligence comes into play. Prof. Ilic claims that currently, most utility companies have extensive records to estimate their long-term average demand, but they use only something like the past 15 minutes of data to predict upcoming surges. I would really like to see a "look-ahead" filter (or model-predictive controller, as Prof. Ilic calls it) on the power companies' demand estimates. This information should then obviously be distributed out to the consumers, who then are incentivised to decrease demand when faced with surging costs.

Obviously this incentive scheme can only be implemented with some form of "smart meter" at the consumer side. It really baffles me why these haven't gone past pilot programs across America. The basic functionality of a smart meter is that it records the power drawn by a consumer, and logs this information over time. More dynamic implementations could go so far as to incorporate an automatic controller. This would be a household appliance (there's an app for that!) that lets the user list and prioritize power-hungry processes as well as input a desired maximum cost of electricity each day. The meter/controller would then use the predicted power costs to schedule the user's processes to run as time---and money---allow.

Smart Meter, originally uploaded by tmvissers.

The funny thing is: This "scheduling" of "processes" already happens in every office and nearly every home in the country. Computers and servers operate on the very principle that some processes have higher priorities than others, and that they will all (hopefully) get done in due time. Except that computers decide between processes thousands of times every second. Should it really be that hard to decide to run your laundry dryer at 1:00 AM and your dishwasher at 3:00 AM?

This pseudo-rant so far has only touched on the "one-way" current model of the power grid. The sexiest topic in smart grid research is how to (best) incorporate distributed power generators. On the one hand, the concept is quite simple: Whereas before a utility user could be viewed solely as a power sink, now there is the possibility of seeing a negative sink (commonly referred to as a source). However, as Prof. Ilic is quick to explain, things are not quite so simple.

All electric power these days travels into our homes on endless sine waves of current. In the US, if you were to stand at one point on the transmission wire, the peaks of these waves would pass you 60 times every second. This standard has allowed for the universal (well...almost) wall plug that all your household devices use. Correspondingly, the power companies transmit and transform the power so that this is exactly what you get at the "tap." When people start generating their own power, there is currently (haha...get it?) no way of knowing that the phase of the user-generated signal will match the phase of the utility-generated one. This phase-matching problem is fairly serious and expensive to control.

The alternative, it has been postulated, is to discourage end users to feed back into the grid. Rather, users should endeavor to store as much of their locally generated power as possible. Now people are thinking inter-disciplinary. Now if you have a plug-in hybrid vehicle, you instantly have a massive battery in which to store your excess power. It's like a two-for-one! The problem is that without dynamic smart meters, everyone comes home from work and at 6:00 PM, plugs in their hybrid and create one of those damned spikes. Now you see how all of these problems are interconnected.

I'll wrap things up with a little utopian vision. My dream house will have several acres of woodland (and be under an hour on public transportation to a major airport) on which I can erect a wind turbine or two. These will provide power to my house as allocated by my self-designed power controller. On windy days, I'll have so much electricity that I'll be able to pump water out of a little stream into a tank uphill from my house. Then, when I need hot water for my bath, I'll suck it out of this tank, through a parabolic reflector and then through a generator, into my tub and use the electricity to run my reading light. Too easy.

Stay smart,

Clay