Figure. A mass versus time plot for the four sinks that form in the \theta = 0 case of CollidingFlows, along with M_Simulation (the total mass in the simulation box), and M_Collision (the total mass in the collision region within the box).

• Time interval is for ~13 Myr.
• Mass axes is logarithmic in order to better illustrate the trend. A linear axes lets the sink masses look close to zero in comparison to the mass in the box and cylindrical collision region.

Followed a similar procedure as to what we did for the ​E vs. t line plots, however did a query for rho instead.

I did the query using both VNC and the interactive queue on both Erica's and my own account on BH2. For the first 200 frames of the M_simulation query, Clover collected most of the data based on the chombos stored locally. Surprisingly, Clover was faster than both VNC and the interactive queue. Ultimately both of these types of remote visualization settings are really unreliable and result in a lot of babysitting. It took me about 3 days to collect all the data for the box and cylindrical collision region in Visit. Here are some issues & interesting things I encountered:

• Want to use a GPU? Need to use VNC which has a GUI. GUIs are super flaky and prone to time out errors it seems. Here is the command to run visit with a GPU though:

    module load virtualgl visit/2.7.3 && vglrun visit

• Attached is the script I used for use VNC. ​CIRC Website also has some stuff on remote visualization (using VNC). It might be faster and nicer to use on data that isn't too demanding on memory.

• Wanted to query using the interactive -p standard for say -t 300. Whenever I tried to do this, after Visit collected data for a few frames, it would time out. Seems like there were some memory issues. So I just stuck to an hour in the debug queue and monitored the memory/cpu percentage on the node I was on. ​Here is a website explaining how to do that. This implies I can only query for approximately 10 frames per interactive job.

• Apparently using query on data that utilizes the cylindrical clip operator requires more memory than just query for the total mass in the box. Visit is probably doing extra work. Just an FYI.

Jonathan suggested making a post processing element in astrobear that'll just spit out all the data into a curve file during a batch job. Think if we want these for the three other runs I will just do that…

Moral of the story: Using query in visit for large data sets is finicky, be careful!

VNC Script

Notes:

• Sign into your machine/local machine.
• emacs vnc_connect_linux.sh -nw
• Paste script in.
• Make sure it is executable and run it.
• It should prompt you to sign into BH2, and for how long you want your session to be, along with the size of the GUI, etc.
• Hit enter when it says a password is found. (FYI) You'll have to make an extra password for your account too when it establishes the tunnel.

#!/bin/bash -i                                                                                                                              
via=bluehive2.circ.rochester.edu
#TurboVNCDir="/opt/TurboVNC/"                                                                                                               
#vncviewer=$TurboVNCDir/bin/vncviewer                                                                                                       
vncviewer=vncviewer

read -p "Please enter your netid: " user
read -p "Do you need to start a VNC server? [y]:" vnc_start
read -p "Set a timeout for your VNC server [60]:" vnc_timeout
read -p "Choose a resolution [1280x1024]:" vnc_resolution

if [[ -z "$vnc_timeout" ]]; then
  vnc_timeout=60
fi

if [[ -z "$vnc_resolution" ]]; then
  vnc_resolution="1280x1024"
fi

if [[ $vnc_start =~ ^[Yy]$ ]] || [[ -z "$vnc_start" ]]; then
  echo
  echo "Now connecting to bluehive and starting the "
  echo "VNC server."
  ssh $user@$via "vnc_start -t $vnc_timeout -g $vnc_resolution" # | grep "vncserver running on " |  cut -d " " -f 4                         
fi

read -p "Please enter server (ie bhx0101:1) " server
host=`echo $server | awk -F ':' '{print $1}'`
display=`echo $server | awk -F ':' '{print $2}'`
port=$(expr 5900 + $display)

echo "Establishing ssh tunnel"
TMPSOCK=`mktemp -u XXXXXX.control`
ssh -fN -o ExitOnForwardFailure=yes -M -S /tmp/$TMPSOCK -L $port:$host:$port $user@$via
echo "Launching VNC viewer"
$vncviewer localhost:$port
echo "Disconnecting ssh tunnel"
ssh -S /tmp/$TMPSOCK -O exit $user@$via

Toward the end of last week I worked on writing a script that would open, read and write the mass data in the sinks_*.okc files to a new .csv file (In particular for the CollidingFlows problem, see our data here: ​CollidingFlowsFigures). The purpose of this was to gain all of the sink data over time, so that we could visualize it, as you can see by the results I have posted below. These charts will allow us to observe how the sinks accumulate mass over the time of the simulation. Here I will document the development of my code, and discuss what else I would like to do with it.

Objectives

Editing code:

• Write information of the density/mass of the cores to a .csv file
• Convert the information from the .csv into solar masses and Myr.
• Take converted .csv file and make graphs using matplotlib, or excel. Excel is quick, but a code that can do all of this and generate plots in one swoop would be super efficient for later uses.
• Document and post concise and general form under the ​VisIt page as a script tab.

So far I have completed the first bullet~ (02-09-2015)

Editing charts:

• Convert mass to solar masses.
• Convert time to Myr.
• Crop the x-axes to when the first sink forms. Get rid of the 0 values.
• Fix x and y-axes to be the same for all the runs.

okc_to_csv.py v. 1

Screen capture of code	Screen capture of .okc file

The code reads the first line of the .okc file, splits the numbers into a list of ints. It then uses those numbers in order to access the data below that starts at the 34th line. The only parts that are hard coded are the headers for the columns of the csv file (L17) and the number of lines of data it has to read into the .csv (L27). Essentially you change this by the number of sinks that form by the end of the simulation. You can check this by counting the number of lines of data that are spit out by the final frame of the simulation.

Results 02-09-2015

Shear 0
Shear 15
Shear 30
Shear 60

New beta, CDM and spectra plots for shear 0 case where done:

​CollidingFlowsFigures

Also did some slight reformatting and added some links.

Check them out: ​E vs. t line plots

Download them ​here. Updated the page to include them as well ​see here.

​CollidingFlowsFigures

Added:

-Tables

-Spectra

-Currently working on E/t plots to post today

-Figures for the Shear15 case

Here is the first round of figures. Essentially this is the reason for lack of blogposts the past few weeks:

​CollidingFlowsFigures

Please check them out! Keep in mind this is the first round, so some of the text on the figures might be weird (dates and such).

Turns out we are calling the wrong position in the array. The expressions should be:

By_downx = array_decompose(projections,0)

Bz_downx = array_decompose(projections,1)

Bz_downy = array_decompose(projections,0)

Bx_downy = array_decompose(projections,1)

Byz_downx = {<By_downx>, <Bz_downx>}

Bzx_downy = {<Bz_downy>, <Bx_downy>}

This yields the following:

Which makes much more sense.

So I am attempting to plot the streamlines for our colliding flows problem. Here is an example of the shear-0 case at 10.1 Myr (or frame 101) (also I did these under Erica' account on BH2 - hence the username haha).

The first image is down the barrel of the two flows (otherwise projecting the mass down the x-axis) thus the vertical axis is z and the horizontal is y.

The second image is a projection down the y-axis. Thus the vertical axis is x and the horizontal is z. This makes sense given that we've defined GxBounds = 0d0,0d0,0d0,62.5d0,75d0,75d0. The two flows are colliding along x, so in the second image, they are coming in from top and bottom.

In both images I've plotted the column density maps for min = 60 and max = 1000. I did similarly for the min/max of the streamlines which are plotted on top of the column density maps. I also checked that they are scaled by magnitude. Now after talking with Erica we are not sure if these streamlines make any physical sense if we have defined a magnetic field along the flow axis (i.e. x). Ignore the visit axis labels as they are generic and don't define the dimensions of our problem.

In our problem.f90 we have defined the projections for streamlines like so:

    !For 'projected' streamlines plot of the data down x:                                                                                                           
    CALL CreateProjection(projection)
    Projection%dim=1
    Projection%Field(1)%iD=By_field
    Projection%Field(1)%component=BOTHCOMP
    Projection%field(1)%name='By'
    Projection%Field(2)%iD=Bz_field
    Projection%Field(2)%component=BOTHCOMP
    Projection%field(2)%name='Bz'

    !For 'projected' streamlines plot of the data down y:                                                                                                           
    CALL CreateProjection(projection)
    Projection%dim=2
    Projection%Field(1)%iD=Bz_field
    Projection%Field(1)%component=BOTHCOMP
    Projection%field(1)%name='Bz'
    Projection%Field(2)%iD=Bx_field
    Projection%Field(2)%component=BOTHCOMP
    Projection%field(2)%name='Bx'

So in Visit I defined a few expressions to be able to plot the streamlines. For down the x-axis (which correspond to the mass1 CDMs):

By_downx = array_decompose(projections, 1)

Bz_downx = array_decompose(projections, 2)

which you can create the expression for the vector Byz_downx = {<By_downx, Bz_downx>} to plot the streamlines like I have above. The first component corresponds should correspond to the right axis if the horizontal component is truly y. Thus the second component will correspond to z if the vertical is truly z. So I think I have these lined up correctly? For projections down the y-axis (corresponding to mass2 CDMs):

Bz_downy = array_decompose(projections, 1)

Bx_downy = array_decompose(projections, 2)

you can create Bzx_downy = {<Bz_downy>, <Bx_downy>}. Clearly from the size of the box we know the horizonal component is z, and thus the first parameter in our vector should be Bz. Similarly for the second being x. However the streamlines don't seem right? Not sure what is going on.

Shear Angle	Final Frame/2 (137)*	Final Frame (273)*
0
15 *
30
60

Table. Magnetic Field vs. Density plots for all shear cases of the "weak-field" simulations (beta 10). The sloped straight line is the 10K temperature, the top horizontal line is the ram pressure, the lower the magnetic pressure. The curved function is the density verses pressure line. Here we have also included a "grey" area, which is the mass weighted density versus pressure post-processing.

* The Beta 10 Shear 15 case does not have a final frame of 273 yet. We are still waiting for the untarring of the rest of the chombos from Stampede. Thus for now I've included 217 and 109 for the middle and end visuals. Will update the table once we get up to 273.

Click open the tab on the following page: ​https://astrobear.pas.rochester.edu/trac/wiki/u/erica/CFRunStatsHighRes

File Transfer from BS & Run Updates

• Went through all of the chombos on visit. All look great, no issues.
• Deleted all of the chombos on BS as I was over soft limit and could no longer write files.
• Been updating Erica's Production Runs page: ​https://astrobear.pas.rochester.edu/trac/wiki/u/erica/CFRunStatsHighRes
• Reservation starting Thursday at 8AM for 5 days. Plan on running B1S60 at 128 nodes, B10S15 at 256 nodes, and B10S30 at 128 nodes. Currently have B10S60 running in th standard queue, already at chombo/sink 157.

Post-Processing & Local Machines

• All of the files I have run on BS are transferred over either on grassdata or bamboodata (some b10s30 (143-153). Can check ProductionRuns directories under madams in grassdata/bamboodata.

• We have the following chombos: 144 (B10S15), 153 (B10S30), 153 (B10S60), and 130 (B1S60)
• We have about ¾ of all the runs done.
• Post-Processing is up to date for B1S60 (completed last night), currently doing post processing on both bamboo and grass (bamboodata) for B10S60 and B10S30 respectively.

​GIF ​GIF

Going Forward

• Reservations on BS. E-mailed Carl to see if he could take off the soft limit for Erica's account, including my own.
• Getting onto Stampede so we can split the jobs between the two machines.
• Need more space on our local machines. Many of our files are scattered between our directories. It would be smart to manage them in the same directories.

Now in full control of Erica's CollidingFlows data on Bluestreak. Completed first reservation (5 days) today. Can see our progress ​here (CFRunStatsHighRes).

• E-mailed Carl about the soonest I can get another reservation (4-7 days on BS). (Update 14:47: Got our reservation extended to next Monday at 8am).
• Erica is working on what is necessary to get us up on Stampede.

Currently:

• scp-ing files from BS to /grassdata/madams/.
• Post-processing on Bamboo.
• Running B10S30 on our extended reservation on BS at 512 nodes for 48 hours (07-28-2014 14:49).
• Submitted B10S60 to the standard queue on BS at 128 nodes for 24 hours… pending, but we'll see what happens.

Some highlights from CFRunStatsHighRes Page:

Going Forward:

• Depending on how quickly we can get onto Stampede, I am estimating that we'll be done with these in 2 weeks if we do this most efficiently.

Objectives

• I know it is about time, but now attempting to make low-res fly-throughs of the .bov files that we already have for our colliding flows visualizations. Plan is once we get all of the high-res data from our production runs, I'll make some nice fly-throughs of those?
  • cp'd code, global.data, profile.data, and physics.data to /bamboodata/erica/CollidingFlows/CollidingFlows/MHD_3D/ to /bamboodata/madams/CollidingFlows/FlyThru/
  • Referencing ​ProjectionObjects wikipage.
  • Need problem.f90.
• Continuing to make .bov gifs for the files as we get them.
  • Bluestreak is currently down until Thursday this week at 8am, in time for my reservation to pick up on Erica's restarts.
  • Erica, Baowei and myself think it will be good to get some code up on Stampede, and run some jobs there. Erica says it'll probably be even faster. I'll have to familiarize myself with how to run jobs there.
  • Having computer issues with Clover and my own personal macbook. Making 3D Box CDM plots is very computationally intensive for these machines…

Mass-1 Column Density Maps

Beta 1

​GIF

Beta 10

​GIF

​GIF

​GIF

So what are different about these than those posted in ​my last blog post? I found the coloring to be too weak on the ones I previously posted. I also did not consider the ratio between GmX and the GxBounds when determining the maximum and minimum. So after going through and visualizing all of the mass-1 .bov sets for Beta 1 and 10 for our production runs, I have decided max = 1000 and min = 190 will be appropriate. This implies, given the size of the box (looked up in global.data), for all beta 10 cases, the mass2 and mass 3 will have max = 639 and min = 121.4. I think Beta 1 has a different box size, but I need to double check.

Again, it seems like I'll only be able to focus on fly-throughs, enhancement, ​somethings I noticed previously about bovs, and getting on Stampede until I can ssh to BGQ.

Visualizations

• Transferring files from Bluestreak to grassdata as we get them.
• Some of the more recent .bov files have been corrupted. Moving the chombos for those to my scratch space so we can do post processing again. Here is what we have so far:

​GIF ​GIF

​GIF ​GIF

Outreach

• PREP Visit: I was invited by PREP (Pre-College Experience in Physics for Girls) to have lunch with the students, and come give a talk on what I had been working on this summer. Titled the talk, "Your Computer: The unexpected frontier in star formation." Covered what we do know about star formation, how colliding flows, and AstroBEAR contributes to the field. We derived the Jeans mass as done in Derek Ward-Thompson's book (i.e. it was not intimidating, just some variable manipulation), and gave them a problem where they can just plug in some numbers and determine whether a proto-star will collapse to a star. I promised them brownies if I got 10 answers by Friday this week. Showed them some simulations Erica and I had done, how we use computers to run code. They seemed most blown away by terminal and that your computer doesn't need to just be used for writing essays for AP English and using Facebook. A lot of good questions, very smart students. Someone from the group should visit them every year.

• Horizons: Erica and I shared the lesson last week (Thursday, July 10th). We had 5 students: one kindergartener, one in third grade, and three who were in middle school. Erica tells me that we only had three this past Tuesday. Today I am hosting the session in collaboration with some graduate students in Optics. We're going to talk about the Sun and telescopes. Hoping if the weather permits (sadly it is expected to be partly cloudy around that time) we'll use a sun-scope and check out some sunspots. Optics is bring some pinhole cameras and telescope demos as they get a lot of this stuff via donation from Edmund Optics.

Our high resolution colliding flows simulations are starting to come in. Erica went through post-processing and here are some CDM. Grass ended up crashing while I was making the Beta 10 Shear 60 gif, so I only have frames up to 64.

​GIF

​GIF

In the previous group meeting, we discussed the comparison plots I made with the different box sizes. Turns out, that by changing the GmX ratio you're affecting the resolution. So given the original ratio of dx = 1.5625, I took Erica's box size of L_x = 200 and applied a GmX of 128, yielding the same ratio. Here is the result.

​GIF

Here we go, as I promised my last post:

​GIF

The Hydro Shear 60, x = 200, y = z = 64 data set has the smallest height and width, so we're seeing whether or not the flow leaving the box was subsonic or supersonic as this case would be thought to be more problematic (due to it being more smooshed). To do this we consider the ratio between the magnitude of the velocity vector \vec{v}, with components v_{i}, and the sounds speed, c_{s}.

So we defined

v_i = \frac{p_{i}}{\rho}, \quad i = x, y, z

and

c_s = \sqrt{\frac{\gamma P}{\rho}}.

Note that P is the Hydro/3DPressure expression in VisIt, i.e.

P = (\gamma - 1)\left(E-\frac{1}{2}\frac{(p_{x}^2 + p_{y}^2 + p_{z}^2)}{\rho}\right),

and that \gamma = \frac{5}{3}.

​GIF

Given that fluid would be sonic at a ratio of 1, we can see that anything orange and red is super/sonic, otherwise it is subsonic. So a lot of the fluid leaving the box is subsonic, however the clumps we see being flung off from the interface of the colliding flows is supersonic. This might be because in this simulation we are taking the magnitude of the velocity, and not just in the z-direction.

​GIF

Above is a simulation for \frac{|v_{z}|}{c_{s}}, we still see a lot of subsonic fluid.

Objective: Going to make a 200x200x200 file, so by the 200th Chombo, the affects won't reach the boundary. Then I'll check the ratio of times for the different box sizes and determine how economical it'll be to have a box size that huge and to what extent we should shrink it.

Now I've included chombos 150 and 200.

Continuing with the previous most I made titled, "Why no sinks?!" Today I played around with some contour plots in VisIt to see if that could be any bit illuminating. The first picture is the 3D contour, looking down the barrel, comparable to the .bov file I attached in the previous post. Then the second image is a 2D slice from the same perspective.

GIF​

GIF

So I think that this might actually be a physical density. Going to make some longer plots as soon as I can.

Here I've made another visual illustrating box comparisons. The min: 0.5, max: 55. For chombo files 0, 50, 100. Now you can compare side-by-side more clearly.

Erica and I are hoping to decide what sizing we think works for the high res runs we're going to do. Similarly for fly-bys.

Consider ​this image that Erica posted on her ​Low Rest MHD Shear Flows page. Note how the Beta 1, Shear 60 simulation becomes the most density at its semi-major axes before any of the other sets.

GIF​

The other two Beta 1 cases (shear 15 and 30) see sinks occur beginning at around 16.5 and 17.17 Myr respectively, however the shear 60 case does not see sinks occur at all. My question is why don't we see sinks forming at those two regions?

As you can see by the picture above, by the end of the simulation the maximum is above 6000, and the minimum is ~24. The maximum is in the ball park for sinks to potentially form, however the minimum is not. Around 17Myr, the minimum is at ~28, and the max is at ~3000.

• Perhaps the density we observe here is physical. Maybe elongating the time on this simulation might result in sinks popping up. Perhaps it just takes them longer to form with a higher shear angle?
• Perhaps the density we observe is not actually physical, but a result of the nature of the .bov. Given the higher shear angle, the more elliptical the projection, and more area for the projection to pick up on at the semi-major axes. This might just be a area density the .bov is picking up on.

Erica asked me to do some tests for the box sizes in global.data with the CollidingFlows problem. Did some side-by-sides for the ~/Hydro_control/Shear60/ set (x = 62.5, y = z = 75), as well as Erica's ~/Testing_Grid_Domain/Shear60 (beta = 0.0, and x = 200, y = z = 64). I also figured maybe we're missing some affects in z, so I increased Erica's test box to x = 200, y = z = 80. Here are the comparisons done in VisIt:

So the first two images seem to be illustrating the same sort of physics — just that perhaps we can see more of what is happening with y = z = 80. The last image (x = 62.5) has the characteristic "hydro" wisps and fingers that we would expect, where as we don't really see these features in the others. The beta = 0 for all of them, and the physical boundary conditions are the same… not sure where these differences are coming from. Perhaps I'll play around more with some smaller sizing. Also a fly through will be coming to all of you soon~

Here are some CDMs for beta 10 data that I got done today. Done for all shear angles in x-field. You'll notice that sink particles form toward the end of each gif (when we'd expect star formation).

GIF​

GIF​

GIF​

Objectives:

• CDM plots with sink parks for beta 1: 15, 30 in x, as well as hydro.
• CDM plots for the other two shear angles to help complete the page Erica is creating.
• Fly through movie for AstroBEAR YT channel with some of these x-field plots.

Here are some plots for the CollidingFlows shear 15 data (beta 1, 10: x, y, z fields, and Hydro). Each of these are column density maps for each .bov file along their respective axes.

Beta 1, Shear 15

GIF​

GIF​

GIF​

Beta 10, Shear 15

GIF​

GIF​

GIF​

Hydro, Shear 15

GIF​

Did the best I could to orient them appropriately without the triade VisIt produces (which is misleading as it does not indicate the actual direction of the flows). The min/max is kept the same for each plot.

Hi!~ so here is a link to my page ​http://astrobear.pas.rochester.edu/trac/wiki/u/madams

Previously I had experimented with making visualizations with Erica's CollidingFlows data on Bamboo during the semester. I created some slices with the Shear 15 data for Beta 1, 10 and Hydro. The most notable effect is how the magnetic field confines the fluid the higher its strength. This is expected, but as I post more in the next few days it'll become more clear for these data sets.

Here I will post some density (rho) plots pertaining to the Beta 1, Shear 15 set with a magnetic field in the x-direction. Each of these movies are slices in the yz, yx, and xz plane.

min: 0.65, max: 250

GIF​

GIF​

GIF​

Notes:

• Attempted to make a three slice visualization with these slices. Visit started crashing on hay. Need to talk to Rich sometime soon about Visit issues.

Objectives:

• Visualizations for density (Beta 10, and Hydro).
• Make some velocity plots for these three data sets (Beta 1, 10 and Hydro).