Team:Wellesley Desyne/Notebook/DanielNotebook

May 30

Yesterday, we went to MIT to gain experience with the laboratory environment in which the users of our programs would be working. Particularly, my current project targets scientists working in chemistry at the atomic level. The project is intended to allow for 3-dimensional rendering of molecular systems. The molecular structure of a compound is intensely linked to the behavior of that compound and the properties of that compound, and so by studying these latter two fields as would a scientist, I believe I was able to gain insight into how our product might be used by a scientist in a wet-laboratory environment.

For example, one of our experiments involved a reaction catalyzed by an enzyme found within a particular cell. We were given four lines of the cell, each with a different modification to the gene coding for the production of this enzyme. Given as the particular portion of an enzyme which catalyzes a reaction is usually small, it would potentially be possible to model such an active site with our modeling software. So, it was useful for us to see what it would be like to be a scientist working in this environment.

I have had some previous laboratory experience through research in a few other laboratories, so this was a bit of a review day for me. However, I've always enjoyed my work in research, and so feel I was able to take hold of the situation and finish our labs quickly and accurately. The only work with which I had trouble was the circuit modeling, because I had never worked with circuit boards like the one present in this lab, and the instructions were not so clear. My partner had taken a class on this, however, and so was able to use her knowledge to help us finish the lab. My inability to work on this project initially, however, did get me wondering about the possibility for an interface to create a model of the system beforehand, so as to avoid confusion if parts of the circuit were not working (initially, our photoreceptor did not work).

All in all, the day was very productive, and I am glad we got to take this change from our usual routine of computer programming to have this new experience.

June 6

Today was another break from day-to-day coding. We visited BU, a lab with which we work closely, and they briefed us on how their projects were going, and what they are doing this summer. I knew before coming to the Wellesley lab that we were a "dry" lab, and they were a "wet" lab, but I didn't know just how different work in each setting would be - after all, both are tracks in iGem. Today, however, I saw not only the great differences between our lab environments, but the importance of both tracks in synthetic biology. BU works in the type of biological lab I once worked in - with pipettes, flow cytometers, centrifuges, and other such instruments for making quantitative data of biological function. Our lab has none of these things. But, the BU lab also has much less coding experience than we do. When they do code, it seems like they really only want to run basic simulations or simple functions - unlike our lab, where we are developing complete software packages. Our lab advisers have really been trying to drive home the point that our work this summer is intended to assist biologists who have less understanding of coding or computer science - and the importance of this became apparent today. I can see how access to a program which runs simulations through a visual interface, or otherwise without requiring knowledge of coding, could really expedite the process at which people like the BU team could undertake wet biological research. It was also interesting to note that many of the BU iGem members shared my major - biomedical engineering - whereas I don't think anybody else in the Wellesley lab is pursuing this track, they are mostly computer science majors. I am actually glad that this is the case - I feel like my work here is going to give me invaluable experience with the type of work that I know I will either be actively participating in or will be helping me with my future wet biological work.

June 14

We're still trying to get double-bond functionality within our program - it's turned out to be more difficult than we first thought it would be. Late last week, we met with one of the previous authors of zMol, for help in both understanding code which seemed confusing, and for advice in moving forward. We agreed that it would be best to eschew the idea of including a torus shape for the double bonds, as this would involve graphical design, with which neither I nor Cassie are very familiar. So, we decided to just change the color of a single bond to indicate a double bond. However, especially in our early stages of trying to develop this, this resulted in a lot of bugs. Particularly, overlapping two single bonds directly on top of each other does not work well in the Unity collision engine, and causes glitches. So, we decided to de-render one of the bonds, in order to prevent this. However, there are still bugs, and still a lot of work to be done in zMol. We haven't even started to really tackle the problem of bond geometry - without correct molecular geometry, it's hard to say zMol can really be used as a classroom tool. It looks good, but it doesn't have a lot of functionality.

June 28

We're coming up on the end of our time with zMol. Orit asked us to start thinking about a new project, zTree, which we will soon be primarily focusing upon. So, in the last few weeks, we've really had to work hard to get zMol functioning well. We were planning for about a week on entering into the UIST conference with a paper on zMol, however, we decided that we did not have enough functionality currently for our project to be submitted. Particularly, Orit was very interested in the potential for our program to utilize haptic feedback, but we have been having too much trouble integrating zSpace and Unity, and understanding how to properly split up zSpace's working source code for programs which implement haptic feedback (their code is not modular enough for this to be simple). But, we have managed to program a 3-dimensional periodic table, complete with a zoom function and search function, which does link to the original zMol program, and allows a user to select atoms which they want to use in zMol. There are now 118 elements to choose from, rather than 4. However, we still have not included ionic nor metallic bonding in zMol, so the vast majority of elements really cannot interact in any way with one another. It seems likely that a future zMol team will have to work on this.

July 3

Monday was our last day of work on zMol and zSeq, and yesterday we started work on zTree. The program is intended to visualize hierarchies of data in a visual format which is easy to understand. Already, we have managed to create one "carousel" of data - the tree will ultimately be made up of a series of interlocked carousels. However, we have been having lots of trouble integrating zSpace and Unity3d - some earlier errors which we thought we had fixed are recurring. We decided to try moving from the "pengrab" script which had been written by prior students back to the pen scripts zSpace wrote. So far, we have the pen's ray appearing in the program, but it does not interact with rigidbodies.

July 10

We tried for a few days to correct the problems we were having integrating Unity and zSpace. Actually, we had a zSpace team member come in to try and assist us with reconfiguring our zSpace machine to allow it to work properly with Unity. For a time, we did manage to get everything to work. He updated our zSpace software, and told us that the most recent release of Unity actually is incompatible with zSpace's current software - so we downgraded Unity. However, soon after this, problems again began to recur, and we decided that for now, we would have to work without any zSpace functionality. This week, we got the foundation for zTree underway. Now that we have experience with Unity, it is much easier to code within its guidelines. Our code for this program is much more modular than zMol was by the time we finished with it, and we hopefully will be able to keep this code commented throughout our work with it, so that future teams will be able to understand what we did. Currently, we are working on just creating one part of the tree - a "carousel," which will be able to rotate around and display different biological parts (or really, any subdivision of a hierarchical structure).

July 15

This week was very fruitful for zTree. Today, Cassie and I are splitting from each other, to allow us to work more quickly and efficiently. I will be working on the "back end" of the program, while she works on the "front end." Already, we have multiple carousels working properly, with the ability to switch between them using arrow keys, an underlying tree structure, and anchors which indicate which carousel is selected. Now, I am going to be working on adapting code from a previous Wellesley project, MoClo planner, to work in Unity, so that my team can use this code in our project. The code is intended to poll the iGem parts registry, and return information on a selected part dynamically.

July 19

Getting that code to work was harder than I thought it would be, but it's finally nearly working perfectly. I had to change a few outdated ways of polling websites which were used in the previous design, change the directory to which the code referred (the site is now parts.iGem.org, rather than partsregistry.org), and fix a particularly nasty bug which generated far too much text per site (it was difficult to identify the error, as the program froze and crashed with each run). There is only one step left now - finding a way to get the "usefulness" field to poll properly. The html code surrounding this data varies, which makes it difficult to find a consistent way to identify this field. Hopefully, I'll come up with something next week.