|
I arrived here in Minneapolis after 11:00 pm on Sunday night. I'm staying with my friend Jenny who lives up here for the week before on-campus housing opens up. She lives in a big house with 6 other people. All of them were really nice. My car was broken into that first night, and a pair of shoes was taken, which I can deal with. I met my mentor, Vicki, on Tuesday. She was running out of town that afternoon, so her grad student, Tim took me around to show me the ropes. I was shown the Graphics Lab and was even given a temporary cubicle. Temporary, as the lab is moving to a new building later this week. I was also given papers to read, and had accounts set up so I could actually use the network. I also can't get keys to the current lab, as I'd get the keys the day before we moved out. Means I can't come in before Tim does, then. More sleep, yay. I read the orginal project proposal, and two papers on Line Integral Convolution, as well as looking at some of the images that Tim has already created. I also started looking at the code, and figuring out what it does. Made lots of notes and comments. The lab moved on Friday. Movers actually came to move everything. The computers are going from one very cramped room to three spacious rooms over in the new building, the Digital Technology Center (DTC). And the cubicles are going to be in a different room also. |
|
I moved into on campus housing on Sunday. I have a double, but with no roommate. And Margaret, my fellow DMPer came up also. Things are slowly getting back on thier feet after the move. Margaret and I need accounts here in the DTC. Until we get those, we can't use the computers here. Haleh, another grad student, and Tim have been letting us into the grad lab, and we've done a bit down there. We also need to get our U-Cards, as the hallway the lab is in is restricted access. We have temporary swipe cards right now. we had our first meeting with the Aerospace professors and grad student who are also working on the project. They gave us a rundown of the physics and stuff behind what we are going to be working on, and why it is important. They mentioned wanting a GUI for the code, and maybe some expansions for identifing other structures besides the hairpin vorticies. Vicki had said we can work on whatever aspect of the project interests us. I don't really want to work on a GUI, so I'll work on whatever else needs to be done. We did finally get our U-Cards and DTC accounts. But, there is no allotted project space here, so we had to ssh into the CS network. Margaret, who just got here this weekend, doesn't have a CS account, so we had to get her one of those too. Finally, we decided to just work from each of our home directories, which means multiple versions of the code floating around, but much easier to actually work. I started expirimenting with some of the GLUT functions (I've never used GLUT, or OpenGL before, so I'm in unfamiar waters). Another thing that came up at the meeting was implementing probablalistic desicions instead of binary desicions. Vicki and Tim suggested the use of alpha values, so i'm looking into that. There was also the DTC open house that weekend. Kind of like the grand opening Margaret and I were to go and present the flow project. Interesting, as I'd only been there two weeks, and Margaret one. Even more so, as Tim wasn't there either. |
|
Continued working on the Alpha Values. Finally figured out how to make them work, (with a few words of wisdom from Margaret). Implemented multiple ways to scale the alpha values based on the input data and results of the region detection algorithm. Got these in for Vorticity, Velocity, and Reynold Shear Stress. I also started trying to keep some instances of the algorithm from growing out of control, without affecting the instances where it doesn't. I did come up with a way to limit it, but the Aerospace people wanted a method more phyisically based, so Bugs passed some ideas over this way. Nothing really too exciting. |
|
A seg fault has popped up in Margaret's code that none of us can figure out. We've all spent some time looking it over. Checked pointers, arrays, etc. Did find some array stuff that sometimes went out of bounds, but it didn't fix the problem. The code without the Interface (done in MUI) works just fine, and the empty Interface works just fine. However, together... she's really frustrated. I can understand why. I showed off my alpha value results at the weekly meeting. Went over pretty well. We did decide which of the implentations best reflected the physical properties. My main task this week was outputing different stats and information files out for Tim and Bugs (the Aerospace grad Student). Not too exciting. I also started working on Documentation of the algorithm. I have a very complete understanding of it, and there isn't much around to ease the leaving of people who know what's going on. So I'm documenting. My favorite thing to do. grrrrrrrrr. I don't really feel like i'm doing much. Hopefully something will pop up that catches my interest. |
|
At the weekly meeting, Ellen, an Aerospace prof, started talking about proximity, and the joining of regions. Bugs said that the current method that he uses is just to check all points within a given radius for another region, but a more elegant manner would be nice. Also examining swirl areas associated with regions could be helpful. So I started working on those. The swirl regions were fairly straightforward, just another alpha value to calculate. But the proximity stuff, now that's cool. How to limit places to look for another region? I decided to merge only those patches that were in a specified region, with areas of low ReyShear stress in between. The boring part was trying to find frame to try my proximity algorithm on. We have 750 frames, and most of them don't have patches that need to be merged. I finally found a couple that I aksed Bugs about. |
|
Got my proximity code working. I think it's cool. It's also fairly specific. I'm sure there have to be other situations where the patches should be merged that the "grow from rey shear" method doesn't cover. So I started thinking about scanning an area out from the end of patch. Started by estblishing Centerlines for each of the patch to determine some orientation information. Currently the centerlines are based on vertical width of the patch, and not at all that the patch is oriented. Causes some problems at the ends of angled patches. I presented my current method, and some ideas for my scanning one at the meeting. Ellen though the scanning method had some great possiblities. I'll have to work on that some more. Went down to Terre Haute and Louisville for the 4th. Lots of fun. |
|
Worked on centerlines again. Figured out a way to originally assign the centerlines, and then adjust them along a different axis, depending on the high and low vorticity patches. Added the functions that allowed that to happen. Some of the centerdots were going berserk. Figured that out though. Silly typos and errors! Some still aren't working quite right. Picking up the wrong vorticity patches, or not picking up some that they should. Started modifying centerlines to work on slightly differnt criteria. |
|
Totally rewrote some of my centerline helper functions. Its now much easier to understand what's going on, and I think easier to relate to the physical representation. Began working on the Scan functions (which were my original goal). Decided instead of to do a point by point search to do a radial search from a base point. Allows for easier blockade detection, and a simple recursive approach. I got the to work. They are kind of inefficent though. Lots of cells are getting searched multiple, multiple times. Especailly for wider regions. |
|
VACATION IN THE ADIRONDACKS!!!!!! woo hoo! (also my 21st birthday!) on the work note, I rewrote the scan functions to be more efficient. Trig is my friend. They had to be written out by hand, as I was in the mountains, and not in the Minnesota Computer Lab. But I did it anyway! |
|
Typed all my lovely chickenscratch into the computer and debugged that. It works pretty well. Scanning forward from the end still leaves jagged lines, and the blockade detection isn't quite up to par. I think the jagged edges are just because the line is at an angle, and the resolution isn't great when dealing with cell by cell. The blockade detection, however is because I didn't take something into account. I think i know what to do though. Made the blockade detection a bit better. Some rays still get through, but I don't really have time to work on that. At the meeting during the week I was gone, Bugs said he wanted me to run the proximity stuff on some larger frames, as well as creating Reyshear packets like the swirl. Was having bunches of trouble getting that to work. As usual, small bugs in the most innoportune places. Ick. After picking through the code and errors with Margaret and a small-tooth comb, we found the problems, and got the reyshear to work for the weekly meeting. Got the big dataset stuff done at the end of the day on Friday. All that is left is documentation now. A blessing and a curse in one... |
|
Documentation, Documentation, fixing stupid trig errors, Documentation, Documentation, Lots of food, Documentation, Last Meeting, Documnetation. Say good bye to Margaret, very sad. More Documentation.... |
| Who am I? | Cast of Characters | Plot |
| The Journey | The Destination | Sanity Breaks |
| ************ | The Beginning | ************ |