I designed a series of three lectures for my fellow astronomy / astrophysics students here at UC Riverside.  The purpose of the lectures was two-fold:

1. To introduce the students to the essentials of N-body methods and computational fluid dynamics.
2. To motivate me to study the subject in more detail and breadth.

Having finished preparing for the lectures, I can say that the second goal has definitely been met.  Two of the three lectures were presented last week and the feedback has been positive, so it seems that the first goal was also met. Tomorrow is the third and last lecture of the series. After that, I will be able to spend time focusing on my research project once again!

The PDF presentation can be found at http://www.idius.net/lectures/N-body-methods.pdf.

There are various ways of merging PDF files.  Here’s a simple method that doesn’t require installing any special software since GhostScript is usually installed on Linux systems:

Suppose the file names are UCR1.pdf, UCR2.pdf, and UCR3.pdf.  Then

pdf2ps UCR1.pdf 1.ps
pdf2ps UCR1.pdf 2.ps
pdf2ps UCR1.pdf 3.ps
cat 1.ps 2.ps 3.ps > combined.ps
ps2pdf combined.ps combined.pdf

The procedure could be generalized and written as a shell script if this becomes a common task. The intermediate postscript files could then be automatically deleted.

Alternatively, there’s a fast free program called PDF Toolkit: pdftk which can do much more than simply merge PDF’s.  There is also a GUI interface for pdftk, called PDF Chain.

I had trouble compiling Splotch 4.0, but I quickly discovered the problem was a small typo in the source code. Once the typo was fixed, the program compiled successfully.  Upon running the program, I encountered another issue.  I investigated the code further and I found what appears to be the problem:  A variable is declared and then it is used before it is assigned a value.

I decided that version 4.0 is too buggy to use as I’m just starting out. I then compiled Splotch 3.1 with OpenMP support enabled.  The compilation was successful on the first try.  However, upon attempting to run the program with the data file and parameter file provided on the Splotch website, I encountered the error message

Cannot find the key "filegas_palette".

I explored the code for a while, but I haven’t figured out how to solve this issue yet. I need to further modify the parameter file in some way, since it was written for the new 4.0 version of the code.  I’ll need to read most of code and review C++ in order to learn everything I need to know about Splotch. There are many parameters which can be set, but there appears to be no detailed documentation as is provided with GADGET.

I suppose I should focus on writing the other proposals before I focus more on reading the source code.

Although I will only be using still frames from Splotch in my immediate research, it will be useful to have the ability to make movies.  Splotch can interpolate between GADGET snapshots and output still frames.  The syntax for using FFmpeg to  create a movie from still frames is

ffmpeg -i image-base-name-%0Nd.xxx -b (bit rate)k -r (frame rate) output-file.xxx

Example:

ffmpeg -i IMG-%04d.JPG -b 512k -r 30 out.avi

which takes files named IMG-0001.JPG, IMG-0002.JPG, etc. and makes an output file named out.avi with 30 frames per second and a bit rate of 512kbps. The 04d specifies that there are four digits in the file name.

Although the viewing angle and camera position can be controlled using the Splotch parameter file, it may be useful to automatically crop images when making a movie for demonstration / outreach purposes.  The syntax for cropping a directory full of jpeg images using ImageMagick is

convert -crop ‘*.jpg[widthxheight+xoffset+yoffset]‘ output_%04d.jpg

The x and y offsets are the coordinates of the upper left corner of the crop box with the specified width and height.  Here’s an example:

convert -crop '*.jpg[1280x720+122+60]' img_%04d.jpg

Which creates images named img_0001.jpg, img_0002.jpg, img_0003.jpg, etc.  Of course any image format can be cropped and ImageMagick can convert between many different image formats.

In the last few weeks I’ve learned more about how the Splotch visualization code works.  Next I need to learn to actually use it.

John Wallin from GMU provided me with a copy of his detailed lecture notes for the graduate n-body methods course that he teaches.  The notes include SPH, the particle-mesh method, the tree method, time integration schemes, and much more.  I was pleased to find out that I had already learned most of the material in his course.  I did learn some important things from the notes though.  At the moment, my main deficiency is that I haven’t written my own code to implement all of the pieces.  John has a parallel tree-SPH code called Mass99.

Except for writing my own code, the best way to learn more about the subject is through explaining it to others.  In the Spring quarter, I will likely have the opportunity to present part of the material in abbreviated form.  I’m considering one lecture on N-body methods, one lecture on SPH, and one lecture on HPC (primarily parallelization and vectorization).

I’ve read the frequently-cited paper, Modelling feedback from stars and black holes in galaxy mergers. In addition to describing sub-resolution feedback, star formation, and accretion, the paper describes the method used for initializing the stars and gas in relaxed disk galaxies with bulge components and dark matter halos.  Evidently many researchers use this method to construct galaxies.  It would be nice to attain a code that implements the procedure described in the paper.  Writing a code based on the description would be a project in itself and some details of the resulting galaxies may differ between this code and the work of other researchers.

Most of my reading lately has involved gravitation.  My second course in general relativity begins next week.

The next step in my research will involve learning to use Splotch.  Once I can visualize the output of GADGET, it will be easier to gain more experience using the code.  At the moment, I’m essentially blind.

I have read all of the GADGET-2 documentation and I’ve read some of the code.  I edited the code in a very minor way in order to prevent some warning messages during compile-time.  I’ve compiled the code and I have run several low-resolution galaxy collision simulations to test things out.

It appears that Splotch will be the best ray tracing visualization tool for comparing simulations with observations. The latest version of Splotch can take advantage of CUDA. I can’t use that particular feature with the hardware in my office, but my home workstation has a CUDA-capable graphics card. The website for Splotch is http://www.mpa-garching.mpg.de/~kdolag/Splotch/ and the original code paper is http://arxiv.org/abs/0807.1742

Once I’ve become more familiar with Splotch and I have more experience with the publicly released version of GADGET-2 code, I’d like to obtain the non-plublic, “full-physics” version.   Then the real fun begins.

Lately I’ve been working on part of an NSF proposal and reading more papers.  The topic of the proposal was not outflow modeling as discussed below.  Today I began looking at the public GADGET-2.0.4 user guide and code.  The code is fairly short considering what it’s capable of. It’s documented well enough to actually understand.  My goals for the end of the quarter are

1. to compile the code and run a test on one of my workstations.
2. read the code in enough detail that I will be able to edit it
3. use a visualization package to view output from my own code or the GADGET-2 code.

During the Winter or Spring quarter, it would be nice to acquire one of the newer, non-public releases of GADGET.  There are several people in the UC system who have access to the newer code.

I’m continuing with the outflow idea. Currently, I’m reading this paper about outflows and IGM enrichment adsabs.harvard.edu/abs/2006MNRAS.373.1265O as well as reading some related works. I should also find out more details about the observational work that Kyle Hiner is planning to include in the NSF proposal.

Lately I’ve been thinking about my contribution to the upcoming NSF proposal. The current idea is to develop a better method for modeling outflows or winds in galaxy simulations. I still need to read more in order to know exactly what work has been done thus far. The main problem appears to be simulation resolution vs computational efficiency. In order to model winds properly, the coupling between electromagnetic radiation and gas must be modeled. Doing this realistically would require the radiation due to stars, supernovae, and AGN to be modeled consistently. From my readings thus far, it appears that current simulations use heuristics to approximate the radiation and the coupling. My goal would be to simulate the input radiation and the coupling in a more realistic way than current methods without significantly increasing the computational effort. In the end, this would likely involve creating more sophisticated heuristics.

Thus far I’ve read a paper describing the entropy-conserving form of SPH which was implemented in the GADGET-2 code. The paper discusses thermodynamic effects such as cooling. I’ve also collected some references that I should read in order to learn more about the current state of energy injection, radiation-gas coupling, and winds.

I’ve read an observational paper by Stockton, McGgrath, & Canalizo discussing Extremely Red Objects (EROs) in two quasar fields at z~1.4.

I read a description of the Particle Mesh (PM) method and a code, by Michael Fellhauer, that uses the method.  I’ve also downloaded the (apparently famous) book “Computer Simulation Using Particles” by Hockney & Eastwood which describes the method in more detail.   The general idea is that we can calculate the potential everywhere on a Cartesian mesh using a Green’s function method to solve Poisson’s equation

The first step is to transfer particle-mass data to the mesh in order to approximate the density .  Then the Fourier transform of the density is computed using FFT (requiring the number of mesh elements in each dimension to be a power of two).  Then a fast Fourier transformed Green’s function is multiplied by the transformed RHS of the above equation and the inverse transform is computed to calculate the potential at the mesh points.  Once the potential is known everywhere, finite difference methods can be used to calculate the acceleration of each particle and then the velocities and positions are updated.

The standard PM method assumes that the situation at hand is inherently static and Newtonian gravitation is fully valid.