Team:Wellesley Desyne/Notebook/DanielNotebook

From 2013.igem.org

(Difference between revisions)
(June 14)
Line 135: Line 135:
== June 14 ==
== 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.

Revision as of 02:05, 22 July 2013

Wellesley Desyne iGEM Team: Daniel Worstell


Contents


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.