Posts in category cameraobjects

New rotating clump without wind fly throughs

Took the wind out of the problem module and added "res" and "temperature," which can be edited for each simulation in the problem.data. Temperature is added to the clump and the res is added to the "Projection Movie." In both simulations they have a res=300 even though they have 1 level of amr. You can see you can see the affect by adding mesh in visit (the image with the mesh is from the second visualization):

movie

problem.data file for this run:

&ProblemData
rho=10
radius=1
temperature=.1
res=300
ncameras=5
/
&CameraData
pos=-10,4,-10
focus=2,0,0
upvector=1,0,0
time=0d0
/
&CameraData
pos=-5,4,-10
focus=2,0,0
upvector=0,1,0
time=.25d0
/
&CameraData
pos=0,4,-10
focus=2,0,0
upvector=0,0,1
time=.5d0
/
&CameraDatasee by adding the mesh to the visualization
pos=5,4,-10
focus=2,0,0
upvector=0,1,0
time=.75d0
/
&CameraData
pos=10,4,-10
focus=2,0,0
upvector=1,0,0
time=1d0
/

Here we have 5 cameras with a starting position of pos=-10,4,-10 that is viewing the clump in the box with an up vector in the y-direction until frame 25 where it switches perspective and moves along the x direction toward positive 10. So the simulation looks like it is moving around while we move in the x-direction over time.

movie

problem.data for this run:

&ProblemData
rho=10
radius=1
temperature=.1
res=300
ncameras=4
/
&CameraData
pos=-10,8,-10
focus=2,0,0
upvector=0,1,0
time=0d0
/
&CameraData
pos=-10,-8,14
focus=2,0,0
upvector=0,0,1
time=.33d0
/
&CameraData
pos=14,-8,-10
focus=2,0,0
upvector=1,0,0
time=.66d0
/
&CameraData
pos=-10,8,-10
focus=2,0,0
upvector=0,1,0
time=1d0
/

Here I am using 4 cameras. In this simulation I attempted to rotate the clump while zooming toward and away from it. The visualization is also continuous as the first and last camera have the same parameters. I think this is quite nice and I prefer this visualization to the first one.

Focus and up vectors

Today I ran seven simulations that play with the CameraData in the problem.data file. I focused on the up vector as well as the focus of the camera. For two cameras I played with a focus {1, 0, 0} and {3, 0, 0} as the previously done simulations have a focus of {2, 0, 0} for all cameras. The simulations I ran with three cameras have the second camera switch up vectors, as well as have cameras switch into ascending or descending order based on the three focuses we know already (1, 2 and 3).

Two Cameras

Run description Image Final Frame No. of Frames CameraData File Link to movie
2 cameras, both up vectors in y, with focus of 1 in x 50 problem.data camera movie
2 cameras, both up vectors in y, with focus of 3 in x 50 problem.data camera movie

Three Cameras

Run description Image Final Frame No. of Frames CameraData File Link to movie
3 cameras; first and last camera have up vectors in y; second camera has an up vector in x 100 problem.data camera movie
3 cameras; all cameras have up vectors in y 100 problem.data camera movie
3 cameras; first and last camera have up vectors in y; second camera has an up vector in z 100 problem.data camera movie
3 cameras; all up vectors in y with ascending focus from 1-3 in x 100 problem.data camera movie
3 cameras; all up vectors in y with descending focus from 3-1 in x 100 problem.data camera movie

A brief comparison considering frame and final times with camera sims

Below I have a table of visualized simulations I ran of a clump and a wind from last week's blog posts:

movie

For each of these little tests I changed the final time and frame number in the global.data file. There is a time for the camera in the problem.data file, so I am also interested in whether or not that time has to be equal to t-final or not and how that affects the simulation if it is changed. No matter the number of frames, the simulation will play out to the same point. Essentially the t-final in the global.data acts as a frame rate, or temporal resolution. You can see that 0.1 final time simulations have a wind that hasn't even hit the clump yet by the end of the run. For the 0.25 simulations, the wind hits it by the end, and in 0.5 the wind envelopes the clump. The number of files, bovs or chombos do not bear on what is "physically happening."

The "camera movies" are made in VisIt like how we would make a visualized bov movie. The camera movies are projections, however they are not necessarily "down the barrel," like what we are use to.

In the chombo simulations I took a slice down the y-axis in VisIt. We know for the camera movies the camera movies along the x-axis, which is does also in Visit. It is a projection of a 3D simulation so we do not need a "z" axis.

In each simulation there are two cameras. One is positioned at pos=-10,2,-10 and the other at pos=8,2,-10. So it is changing in the x-direction, but keeps focused on the same object as it moves away from it. Both cameras have a focus of 2 in the x-direction.

So the camera is positioned outside of the box and integrates the density through the domain - in essence it is a column density map.

Why I did this is because there is a time for each camera in the problem.data file. For the nth camera, should we have its time equal to the final computational time in the global.data file?

0.1 Final Time 0.25 Final Time 0.50 Final Time
10 Frames
camera movie, 10 bovs camera movie, 10 bovs camera movie, 10 bovs
chombo movie, 10 chombos chombo movie, 10 chombos chombo movie, 10 chombos
25 Frames
camera movie, 25 bovs camera movie, 25 bovs camera movie, 50 bovs
chombo movie, 25 chombos chombo movie, 25 chombos chombo movie, 25 chombos
50 Frames
camera movie, 50 bovs camera movie, 50 bovs camera movie, 50 bovs
chombo movie, 50 chombos chombo movie, 50 chombos chombo movie, 50 chombos

Fly through test 2

Yesterday I got a new code and checked out development. I then made a new problem directory in my code to run Jonathan's problem module and .data files from BH2. The code made eventually after fixing the HYPRE path and CPP errors. It seems we didn't see the clump with the first test as I ran a 2D simulation, so this time my global.data has nDim = 3 and Gmx = 32, 16, 16. I ran the executable twice for 0 and 2 levels of AMR (see results below). I ran them both out for 100 frames, so the camera seems to move from one position to the next at a slower rate in comparison to Jonathan's simulation that only has a few frames.

Currently I am trying to understand how the camera works and run some simulations with a different camera position, focus and up vector. I'll post those results once they are done.

0 Levels of AMR

Chombo movie

bov movie

2 Levels of AMR

2 levels of amr chombo frame 0

Chombo movie

fly through projection

bov movie

Fly through test 1

Currently trying to replicate Jonathan's simulation johannjc09292014 so then I can apply his method to setting up the cameras to our problem module for CollidingFlows. So in Jonathan's problem module he sets up the cameras, makes an ambient to fill the grid, puts a clump in the ambient, and then puts a wind in the box.

Last week I made the code incorrectly due to my own lack of understanding. This time I created a new problem directory and threw in his .data files and problem.f90 to make a new executable. I did this using scrambler_3.0 that I copied from Erica's directories. I ran into an issue when I tried to make the code:

modules/Problem/problem.o: In function `problem_mp_problemmoduleinit_':
modules/Problem/problem.f90:(.text+0x3ef): undefined reference to `updateprojection_'
make: *** [astrobear] Error 1

So I went into Jonathan's problem.f90 and commented out

CALL UpdateProjection(Projection)

and it made the code without any errors. The results from the simulation are below. We still see rotation in the frame, however it does not look like Jonathan's simulation still. It rotates into the wall and then zooms up on it. I only included ¾ of the simulation since I did this on my personal laptop and it was taking too much time in visit while ssh-ing into Bamboo.

So now I have got a new astrobear and trying to do the same process again (this time hopefully not needing to comment the call to update projections).

movie

Here is what the chombo files look like:

movie

Essentially there is just a wind coming in.

Meeting Update 10/27/2014

Visualized my fly-through data. It isn't right; seems like it just follows the corner of a box. Didn't implement the tracers last time since it was just a test of the code, so I figured it wouldn't look like our problem. That is the next step.