gravity and buoyancy

Well, I got gravity and buoyancy working with Paul's help. I wrote up the calculations and sent them to Tarynn to see if they are right. Here are some results of tests that she asked me to run:

(a) no gravity means everyone should just float upwards
they head up to the top first, slam into the ceiling, and start bouncing back and forth between the ceiling and the floor.

(b) no buoyancy, no velocity, and everyone should sink
they head down to the bottom first, slam into the floor, and start bouncing back and forth between the ceiling and the floor.

(c) no velocity, gravity equals buoyancy and nobody should move
setting the density of the fluid equal to that of the parasite, gravity equals buoyancy and nothing moves.


So, major progress. Still lots to do though.

Spring semester

I admit, fall semester was not very productive. I spent most of the semester trying to figure out why simrender quit working after I reinstalled everything when I got a new harddrive (100GB! beautiful). Meanwhile I tried to add gravity and buoyancy to the vector updating, and played with a function that would (hopefully) take a 3D point and display it on a 2D plane so that it kind of looked 3D. However, it bothered me because I couldn't really trust what I was seeing.

At the end of the semester I borrowed a laptop from the Westmont CS department, put my old harddrive in and put the two side by side, comparing all the settings for compiling simrender. I verified the old one worked, and then as a test, recompiled it, and it stopped working! So I copied off a fresh version from the backup CD I had made after the summer (so glad I made that). Eventually I realized the problem: at the beginning of the semester I had gotten the bright idea to install a new version of DrScheme because it had some new features. It didn't like some of the functions that were in my code, so I tweaked it, and it would run. What I didn't realize was that simrender did not like this new format. So I went and got the old version of DrScheme and it worked great. I made note of what version to use in the readme for my code.

So now it is spring semester, and I need to write up an application for research credit before the add/drop deadline (Wednesday). Part of that is figuring out what I want to accomplish this semester. I'm hoping that I can get the little parasites bouncing around according to physics by summer. I need to make it sound better than that though. It is discouraging that my goal has gotten that non-ambitious, but I just don't have the physics background. If I can get gravity and buoyancy working, then Tarynn can come out and I'll have a few days to make her explain all the other equations to me.

I did make a breakthrough tonight though. I've been trying to think of how to figure out how simrender handles time short of e-mailing the guy who wrote it and asking. So I set up a few tests. As it turns out, one timestep corresponds to one "second" in simrender. Very handy. Whether it's actually a full second or not depends on how fast your computer can go and such. So now all I have to do is set up the physics stuff so that a timestep is a second. I hope the units come out ok.

I wish I could condense my code--there is so much of it. But then if I'm going to have to re-write it in a different language anyway, there isn't much point. But I don't know if that'll happen...

End of summer

Once again, they are bouncing... I think. The way that Tarynn came up with to troubleshoot my calculations suggested a shortcut in the calculations. A really short shortcut actually--it took like ten minutes to program in. And now what John said a few weeks ago finally makes sense--the only part of the vector that needs to be changed is the part that is normal to the plane that it is hitting. So instead of setting up a local coordinate system and using trig to flip the vector around, we can take the vector and change the sign on the coordinate that corresponds to the wall it is hitting. It seems strange that it would be that easy so I want to test it a lot more. I learned a LOT more about vectors than I would have if I had just started out with swapping the sign though. So I think greater confidence when dealing with vectors is worth the extra work.

I ran some tests with the new way of calculating: first with the parasites starting in the middle and then bouncing straight back and forth against the walls (left-right, top-bottom, and front-back) and then I also tried one where the parasites bounce back and forth catty-corner. It passed with flying colors. I also tried one where the parasite hits the middle of each side (right, back, left, front, etc). That one also worked. So eventually I made a file with around a hundred parasites all milling around and it looks pretty good.

It did look like it was doing a few strange things though. Occasionally it looked like the parasites were skating along the wall a small distance before taking off again. Occasionally it also looked like they were bouncing against the same wall twice. It was a little difficult to see, and it could just be the 3D perspective. I may need to run the binary file through Ford's program and actually look at the numbers. I can't think of anything in the program that would cause this, but we'll see.

I'm keeping a copy of the latest versions of the prototype--both the new way of calculating and the other way too (I spent too much time on it to delete it. and it may come in handy later). Both are commented like crazy so I should be able to figure out what is going on if I come back to it later. I also wrote up a readme and I'm putting together a CD for Tarynn with just about everything on it. When I get home I need to burn my own copy of the CD too.

The summer ends how it began--with lots of paperwork and presentations. Check my website in a day or two for links to my research presentation and my research proposal for the academic year.

They Bounce! (mostly)

Well, in the process of testing the program to figure out why the parasites were sticking I found a problem. As it turns out, I had tried to be cute and given the program too many normals to choose from which made the parasites keep updating to the same velocity which made them look like they were sticking on the wall. So I fixed that, but I found out that when the parasites are bounced straight off of the ceiling, floor, back, or front, they will also stick. Because when the prime axes are calculated they come out to (0, 0, 0) which makes everything zero when the vector is updated. So I'm waiting to talk to Tarynn on this because it's a problem with either the math or how I'm understanding and programming the math and I'm not sure how to fix it in a mathematically legal way. I'm not exactly sure that some of the vectors are reflecting properly, but since they reflect correctly off of the walls which are working (the right and left) I'm going to focus on fixing one problem at a time.

The good news is that I can run the simulation and watch parasites bounce off of walls ad infinitum as long as none of them try to run straight into walls. On the last simulation I ran only two out of ten parasites stuck. But I'm going to need to add a lot more to this because, quite frankly, it looks silly. Parasites don't just bounce back and forth between two walls, they change direction. However, it looks like I will have at least something to show for this summer, lol.

Philippians 4:6-7, 2 Timothy 1:7.

IT WORKS!!!!!!!

Ford came over today and we looked at my code. He thought the problem might be that I was setting the length of each number to 4 bytes, so he wrote a quick program in C++ that would read in my binary file and display the numbers in ASCII. So he tests it a bit and then pulls up a list of numbers and asks "are these the radii of the cells?"

Oops. Turns out there is not just one number for the radii at the beginning. There is supposed to be one radius for each cell. And then the list of coordinates starts.

I am happy for several reasons:
It was an easy problem to fix.
I was right--it was reading in the wrong numbers for the wrong things. Kind of like a frame shift, but not as bad of one as I was thinking it might be.
I now have a program that will display my binary file in ASCII with markers for when the radii start, when the x y z coordinates start and when each timestep begins.

Once I added that list of radii it worked great, and then I put in a conversion so that my x y z coordinates show up correctly on the SimRender coordinates. So the hostcells now show up on the "floor" and parasites bounce around properly. Here's what it looks like now:


Yellow are host cells, red with green vectors are parasites. The green brackets are just selecting that cell.

There is only one problem. For some reason, the right hand wall is sticky. All the parasites hit it, or even end up outside it some how, and stick. Because of the way the world is set up, that wall is actually controlled by y-minimum in my code. So for some reason when a parasite's y-coordinate is less than or equal to 5 (y<= 5), the velocity turns to zero. This does not happen on any of the other walls. I checked the code and I can't find anything different about y-min...

very odd.

Frame Shift?

What I wouldn't give for an extremely detail oriented person right now...

It should be simple. Give SimRender this list of numbers, and it will display the parasites moving according to those numbers. I tried to follow what Ford gave as the format exactly. But SimRender is not reading the file properly. It's almost like... a frame shift. If I were to give an example of what I think is happening: Say I give it

10 20.432 30 40 50 60

And then it reads that as:

102 0.4 32 30 405 0 60

But it isn't a pattern that I can look at and say, oh, this is what is wrong. Maybe it is different because it's converted to binary first and there are extra bits or bytes or words or THINGIES that tell it whether it is signed or not.

I need to know EXACTLY what SimRender is, taking NOTHING for granted. Things that are default in C++ have to be manually set in Scheme.

As it is I'm going to have to make up some kind of formula to switch x y z coordinates to the coordinate system that SimRender uses (he swapped the y and z axis, and the origin is in the back lower right corner instead of the back lower left corner).

[vent] I hate not having all my ducks in a row like this. In order to make this work I need to know where all the pieces are and how they fit. And I don't. SO frustrating. And there are only about 10 days till I have to give my presentation. And there is more to do beyond just getting it to display. ARRRGH. [/vent]

SO close...

I'm torn between doing cartwheels and crying in frustration.

My Scheme program outputs what I think are the right numbers in the right order in the right format to the right file. AND SimRender finally will open it!!!!! YAY!!! That's the cartwheels part.

However, SimRender is not supposed to take what I gave it and display this:


The spheres are supposed to all be pretty tiny. Instead they are all different sizes from huge to small, a lot of them are outside the world (you can barely see the wire frame box in upper left part of the screen shot), and I'm not sure they are moving correctly. Sighs.... AND I don't know what's wrong. That's the cry in frustration part.

Thanks to Kyle for help with getting SimRender working, Michael for help with linux, and Dr. Iba for help with Scheme and binary.