Skepticism in My Photonics UROP

I've mentioned here on several occasions that I've been doing a UROP regarding nanophotonics/photonic crystals. Specifically, my first project was in determining whether particular types of photonic structures might enhance absorptivity of light, which would help solar cells that convert that light into electricity. The goal is that the absorptivity enhancement (versus no texturing over the solar cell) should be over as broad of a frequency band as possible, because it is difficult to manufacture many different kinds of photonic structures just to satisfy performance demands over many narrow frequency bands. I worked on this project for about 4 months, because that was the time that my postdoctoral UROP supervisor was around (he moved after that). I was able to get some really nice-looking results in that time, and I figured there wasn't much more I needed to do to wrap it up, so I felt comfortable generally moving on to a new project (which I have been working on since 2012 February or so). The enhancement results looked great compared to existing designs, so I thought we might be on to something here. Recently, things started gearing up for a publication submission.

Today, it all came crashing down. Why? Another postdoctoral UROP supervisor (who I have worked with since last year primarily on my more current project but recently joined in to help progress of the older project, which is the subject of this post) asked me some hard questions about what I was really doing. Because of this, I realized that one of the parameter choices in my calculations that were giving such nice results was fatally flawed. When I fixed that issue, the results I was getting suddenly looked significantly less compelling; with that, any dreams of publication were dashed.

Why did this happen? It boils down to me not being skeptical enough about what was going on. A large part of this has to do with the fact that because this was my first UROP, I didn't have a great idea of what was going on in terms of details. And because that time I spent was only about 4 months and was followed immediately by a new project, I didn't spend much more time on that project after that. Ultimately I got complacent in more ways than one. Because the code I was using was based on existing code for similar calculations, I figured it must have been written to work even with the modifications I was making. I also figured that because I had been getting consistently good results from what I had done over those 4 months, I just needed to worry about those results on the surface and not the fundamentals operation of the code. Those two assumptions combined such that even though I had seen the results of not being careful in my second UROP project and had become much more careful about checking that code as a result, I didn't think I needed to apply the same level of care in checking the code used for the first project.

After realizing the implications of this, I did a few more calculations in a significantly more mopey mood. But then I thought about this and I realize that I shouldn't feel so bad about this. Why is that? Here are a few reasons in no particular order.

1. I've made similar mistakes before, and I've really come to learn from them. One example of something that I thought was going great but turned out badly has to do with email. People who know me may have heard this story, and people who have known me for a while may have actually been there to see me do this, but I won't share the story now; I believe it is sufficient to say that I am now a lot more careful when sending emails especially to large groups of people. A reverse example actually comes from my second UROP project: for a while I was making a mistake in my code that was giving garbage, but after many months of trying various fixes, one particular fix solved all the other issues. Since then I have been a lot more careful about checking my code for that project (though I guess I was confident enough about the code used in the first project that I thought such a high level of care might be unnecessary).

2. I didn't think I would be in the position of having my work for both projects on paper until very recently. Now I can go back to thinking that in any case my second project work would be more likely to go on paper (especially as I know that I have taken a lot more care in checking my code for that project).

3. Several months ago, when my second project was stalling, I was asking myself why it wasn't going as smoothly or quickly as my first project. Now I know that the first project should have in fact gone as slowly as the second project for the work to become as solid and carefully checked. The other part of this issue is that I have been working on the second project continuously, so I have been able to make continuous adjustments to the code and work progressively higher levels of care in checking the code in a smooth manner. Because I essentially stopped working on the first project after those first four months, if I adopt more careful code-checking now, it'll feel more like I'm starting over from scratch, which makes the process feel a lot more frustrating.

4. With all this, I feel like I have already learned a lot more from this lesson than I would have if everything was fine and dandy and this work did get submitted for publication.

5. If nothing else, I hold out hope that I may be able to salvage some good results with the fixes I have made to the code of the first project.

There are two morals to this story. The first is that I shouldn't just check the code I run; I should check it in an actively skeptical manner, always questioning each and every line. The second is that C++ is way more painful to read and (to a lesser extent) write than Scheme is for the kinds of calculations I run.


Featured Comments: Week of 2013 July 7

I didn't post anything in the two weeks before this past one because I didn't really have much to post (not because I was particularly busy). This past week, there was one post that got a handful of comments, so I'll repost some of those.

Review: Korora 19 "Bruce" GNOME

Reader Barnaby said, "Skype works fine with Debian and Slackware 32-bit systems, probably Redhat based ones as well. I wouldn't blame errors with software installation in a live session on the distribution though, some things need a proper install, like the force switch to ignore the architecture."
Commenter arindam sen had this to say: "I agree with Kevin, 64 bit skype is required for Linux. It takes a bit to install the 32-bit Skype in a 64 bit OS and if you are not using Ubuntu/Debian, life becomes a bit tougher actually. There are some quick fixes suggested for Fedora/Kororaa but at times they worked for me and many times they didn't. So, it may not be the fault of the OS. Also, Gnome 3.8 is quite buggy compared to KDE. I reviewed Fedora 19 Gnome 3.8 (32-bit) and it is no where close to the performance offered by Fedora 19 KDE (4.10.4). Plus, I found GNOME a bit counter-intuitive to use. I really loved GNOME2 :(."
Reader dnlcerqueira had this to share: "I use Fedora 19 x64 and just installed the 32bit rpm without any problems , skype works perfectly on my pc."
Commenter crabdog countered, "I've tried the last few versions of Korora but only in VirtualBox. It looks fantastic and I really want to like it but it always seems very sluggish although my system has nice specs. Perhaps it would run better from a live boot and most likely better again on a proper install but for me if something doesn't run well in a virtual machine it doesn't get another chance."

Thanks to all those who commented on that post. This coming week, I may have another review out (or I may wait a bit). Anyway, if you like what I write, please continue subscribing and commenting!


Review: Korora 19 "Bruce" GNOME

Activities screen
In the comments of my review of Korora 18 "Flo" KDE, a bunch of people asked me to review Korora 19 "Bruce" GNOME. Now that this new version is out, I'm going to review it. It hasn't been too long since my last review of Korora, so I'll skip the introduction and get right to the main stuff. I reviewed the 64-bit edition (usually I review the 32-bit versions of distributions essentially by default, but this time the 32-bit edition seemed rather delayed to the point when I first downloaded the ISO file, I was under the impression that Korora might have dropped 32-bit support) on a live USB made with MultiSystem. Follow the jump to see what it's like.