Here's a snapshot of the first frame. There is a parent clump and three child clumps all with radii equal to the jeans length for the density… Additionally the parent clump has a radius equal to the jeans length for the average density of the clump (including it's children)… Soon will extend this to several generations of clumps.

Ruka's Bondi Hoyle problem has been successfully implemented to the test suite complete with bear2fix.data files and images. I also updated the test suite page, so that it now contains information on what our testing procedures actually do. The OrbittingParticles test will be coming soon; I just need to resolve some runtime Hypre errors. Also, Matt is working on the wiki integration which should also be finished soon.

Hi folks, just wanted to share that my second clumpy jets paper just got accepted to ApJ!

Woo!

Note to self: do not take 6+ months to respond to referee report on next paper…

I found a very easy way to generate jpeg images of various processing objects (ie projections of column density) at runtime (or post processing). There is an image format called ppm that is essentially ascii text that can be converted to a jpeg using system calls. Also added code that checks for a postprocess script in the run directory and if present executes it passing in the frame number as a 5 character string. This can be useful for scping chombo files to a longer term storage, or sending jpeg files to a web-accessible folder for monitoring simulations in ​realtime…

#!/bin/bash                                                                                                                                                                                                                                   
mv out/Mass_along_3_$1.jpeg /home/johannjc/public_html/CollidingFlow.jpeg

Also created cron jobs to back up the wiki daily, weekly, and monthly. In the process discovered that the raid_array scripts that e-mailed folks if the arrays were in trouble was lost in the reconfiguring of grass and clover. (And alfalfa is in need of one). Currently working with Dave to get these back up.

I have been debugging this past week. I ran into some issues with linked libraries (or lack of) on bluehive for the updated version of the code I was running. After fixing that, there were some apparent problems with the simulation I was running. I tracked down those 'bugs' (some code had been left out for the initialization of ambient objects from the newer version of the code I pulled) and have since submitted the jobs to bluehive. The queue is a bit laggy right now, but hope to finish the prelim sink tests and beta rotation study by the end of the day tomorrow, given all goes smoothly with the jobs in the queue now..

I also added functionality to buildproblem to check the bear2fix.data.img on clover to determine the frame number that should be uploaded for each test. That should fix the issue with FieldLoopRestart. In addition, the astrobear log file is now added to the test log uploaded to the SVN repository.

Finally, I updated the buildproblem -d parameter to check out the latest copy of astrobear. For example:

buildproblem -d ~/astrobear/ -t -np 2

Will check out a fresh copy of the code to ~/astrobear/, and run all tests with 2 processors. If ~/astrobear/ already exists it will not check out the latest copy, presuming you want to run with the older version already present.

The OrbitingParticles test and testing compilation with various flags are still under development. The RadiativeInstability tests need to be optimized to only produce the chombo that will be used for the test, not for an entire run.

The infrastructure for testing is in place, with the exception of wiki integration.

Concerns for the meeting will be:

1. Should the directory structure used in the tests repository be modified to be easier to read?
2. Should the "history" of tests be reflected in various SVN revisions or by date directories (as they are now)?
3. Final functionality required for wiki integration.
4. Bear2fix updates.

Magnetic cloud shocked by mach 3 shock. See project page bottom.

See my latest research report at: ​https://clover.pas.rochester.edu/trac/astrobear/blog/category/Meeting-outline

I've updated the wiki with documentation on processing objects linked from ScramblerIntro

I've also updated the GravoTurbulence and the CollidingFlows pages with more results.

Made a page that puts all 4 of Martin's movies side by side for comparison. ​http://www.pas.rochester.edu/~blin/crl618/stratified.html

CLUMP ​http://www.pas.rochester.edu/~blin/crl618/stratified/clumplineout.gif

JET ​http://www.pas.rochester.edu/~blin/crl618/stratified/jetlineout.gif

Dec 6:

• The Bondi module is now in the test suite.
• Still working on my paper.

Nov 29:

• I've made some cosmetic/usability changes to the Bondi module. Cleaned it up, added lots of comments, all relevant variables moved to problem.data.
• Next step: need to talk to Eddie about adding the module to the test suite.
• Got the first draft of my paper back from Martin with lots of constructive criticism. I am planning on revising it today and tomorrow before submitting another draft. I will focus on this first and then copy over portions to the wiki page.

Nov 22:

• This week I've mostly been working on the term paper. I've submitted a first draft to Martin earlier this afternoon. Over break I will edit/revise it and then add the information to the testing page on the wiki.

See the Magnetized Clump Project page for the updates. As always, scroll down to bottom for new images and animations.

​https://clover.pas.rochester.edu/trac/astrobear/blog/category/Meeting-outline#martinsOutline

Go to Image of the Day for instructions on adding your own png images.

The bear2fix routine that compares chombos was altered to be more easily used with the test suite. The errors are now consistent with what is described on the Test Suite page. Basically, the relative errors are now computed as the error relative to the reference chombo as opposed to relative to some average. Due to some foresight on Matt's part (when considering wiki integration), the data in the output files is now formatted as floats with one number on each line.

Now that build problem and go.s are fairly robust, the following remains for wiki integration. Let me know if you believe there is a more efficient or effective way of organization.

I created a new SVN repository at /data/repositories/tests on clover. This repo is currently integrated under the Browse Source tab.

This repository will store files of interest from /data/tests on clover.

The files will be organized as follows:

testname/logs/[date]/(testlog, rel_errors.data, abs_errors.data)

testname/images/[date]/sim.png

testname/images/ref.png

after go.s runs, the entire /data/tests directory will be checked into the repository. All files in this directory will be ignored except for those mentioned above.

A wiki plugin will be created which iterates through the repository and embeds the images in a wiki page. For example:

[[Tests]]

would output the references and simulation runs for all tests for all dates, as well as a success or failure flag.

[[TestList]]

would output a list of all tests currently on file in the repository.

Since only one reference is listed in the subversion repository for each test, any changes to this reference should the original be determined inaccurate would automatically update on pages using this plugin. One concern is if Trac will allow me to modify the "success" flag to invalidate all test results preceding the date of the reference change.

The results could also be culled. For example:

[[Tests(FieldLoopAdvection, 11-11-2010, 11-11-2011)]]

would output the references and simulation runs for the FieldLoopAdvection test over the course of a year. This will allow for more complicated WikiFormatting structures, such as comparisons between test runs of different dates in tables.

Specific data can also be represented:

[[TestResults(FieldLoopAdvection, 11-11-2011)]]

would only output "success" or "failure" for the FieldLoopAdvection test run on 11-11-2011.

[[TestSim(FieldLoopAdvection, 11-11-2011)]]

would only output the the simulation picture for the FieldLoopAdvection test run on 11-11-2011.

[[TestReference(FieldLoopAdvection)]]

would only output the reference picture for the FieldLoopAdvection test.

Please let me know what features/data culling abilities/syntax you would like to see if it is not adequately represented in the format above.

New plots and animations on the magnetized clump project page. (scroll down to bottom)

There are several plots I need to generate for the colliding flows problem (and the gravo-turbulence problem) that cannot be generated in visit - 2D distribution functions, column densities, total particle quantities. There is also no easy way in Visit to plot the total particle mass as a function of time… So I've added some processing routines to astroBEAR that can be done during the simulation or after in a post-processing mode. So far I am not generating any images directly - so no new libraries (pgplot, matplotlib, etc… although this might be a nice thing to add eventually), but instead generating the raw data for the plot so the actual plot can still be customized in visit.

​http://www.its.caltech.edu/~appelo/ae232/lecture1.pdf

You have to change the lecture # to step through the series

It works, it works!

Here are the (semi) latest runs of the Bondi Module:

​Rho Lineout
​Velocity Lineout
​Velocity Pseudocolor
​Rho Pseudocolor

Beyond this, I've made some changes to global.data and physics.data, and the module also works properly now for the numbers Shu gives in Physics of Astrophysics II. However, the kink at r~0 still persists in all the chombos except for the very first one.

I have created two tickets in regards to executing bear2fix scripts.

Please see the tickets #159 and #160 for more details.

UPDATE: Issues have been resolved. Bear2fix integration should now be usable.

Starting new runs of CRL618 implementing diffusion and without (no rings at the moment, with rings later). Currently working on a faster implementation, as the latest setup has been stalling in Bluehive with low dt's.

​http://www.pas.rochester.edu/~blin/crl618/plot.pdf Link to CRL emission and PV maps Martin did couple of weeks ago using powerlog normalization.

Just wanted to encourage people to never copy files from one astrobear repository to another. This essentially corrupts the repository since mercurial will assume the changes to the file were intended. It is difficult to debug corrupted repositories since it is no longer clear what modifications to the source code have been made, and a corrupted repository should never be committed since that will potentially (and quietly) undo bug fixes. If there is a repository with modifications that you would like to replicate in another repository, you should commit those changes to the first repository and then pull that changeset to your own repository. This way mercurial knows where the changes came from and can correctly merge those changes with any that you might make down the road.

Copying data files is not as 'bad' as long as the copied data files are never committed. (Just use hg revert *.data before you commit). If you do want to update the data files in the repository, then you should not copy them from another directory, but instead commit the changes in the directory where you first modified them - or revert them and replicate the changes manually.

Also, you can commit individual files so if there is a single bug fix in a single file, just run hg commit somefile.f90 and then pull that change to the other repository and update or merge if necessary.

I have completed updating my hydro code with a second order MUSCL-Hancock scheme. See the comparison plots on my buildcode page (scroll to the bottom). Also, I finished updating all of the content on the page which now includes short descriptions of the approximate Riemann solvers and the MUSCL-Hancock scheme.

The last few chapters of Toro deal with source terms and higher dimensions. Should I implement either of these into my code, or should I now move on to the hand-full of AstroBEAR development projects that I have on my plate?

As far as testing goes, I'm working on the OrbitingParticles problem. This one is a bit tricky because I want to produce an image of something visually insightful which is no problem with Visit. However, we want the post-processing scripts to be easily used for all tests which requires us to produce images with bear2fix. So I may have to add some code to bear2fix, but I have to think about this some more. Any ideas on what might be the easiest yet insightful thing to plot for this problem?

Banerjee and Pudritz employed an EOS that was density and time dependent. They also incorporated radiative cooling into their model and studied both the isothermal and non-isothermal phases of the collapse of rotating BE spheres. As this is already much more complicated than our current rotating BE clumps, not sure how much of an overlap in results we can expect. Furthermore, they report seeing no fragmentation or 'non-central' collapse in the isothermal phase.. :/. (Currently the setup is only isothermal).

​https://clover.pas.rochester.edu/trac/astrobear/wiki/u/EricasLibrary

So I hope this isn't too silly, but, on an aside, if one does not initialize differential rotation, can the simulation relax to such a state on its own? Is this possible without the equation for such rotation explicitly written into astrobear? Or, do all numerical models operate on "if this condition, use this equation, for this q variable"? ..

'astrobear_mercurial_test' @ bluehive is where current build of astrobear was made

The repository here is a blend of the most recent developer source and johannjc's changeset with correction to the *Subroutine Finalize Accretions*.

I have modified the files here to include write statements in particle_control.f90 L261 for the sink particle's location, dQ array, and d(rmass). Also, I have added a write statement in the particle_info_ops.f90, L519 to report the gradient of phi.

In addition, I have modified the BE problem.f90 to induce collapse and omega rotation parameter.

Is the next step for mercurial to check in these changes and then merge?

Two jobs are in the queue @ bluehive:

1) I am re-running the 86³ fixed, shifted ½ dx in x and y with the new print statements to plot the changes in the above params over time.

2) Rotation of BE sphere.

I'm running simulations of large (80 pc) diameter clouds that are initially virialized that undergo collapse. Here is an image of the Temperature early on after the initial velocity spectra chosen so that \hat{v}(k)\propto k^{-3/2} which should give a 1D energy spectra E_{1D}(k) \propto k^{-2}

So the uniform density collapse problem has a self-similar solution where \frac{t}{t_{ff}} = \frac{2}{\pi} \left ( \eta+\frac{1}{2} \sin(2\eta) \right )

and

\cos(\eta)=\left( \frac{\rho}{\rho_0} \right )^{-1/6}

Since \frac{R}{R_0} = \left ( \frac{\rho}{\rho_0} \right )^{-1/3}

\cos(\eta)^2=\frac{R}{R_0}

If we plot \frac{R}{R_0} as a function of \frac{t}{t_ff} we get the following.

Since the curve looks like a circle we try a polynomial expansion y=a+bu+cu^2 \mbox{ where } u=\sqrt{1-x^2}

The best fit (plotted above) has coefficients a=.7178 \mbox{, } b=.3068 \mbox{, } c=-.01842

If we then use this to scale the size of the window, the apparent radius of the cloud remains fixed as it collapses. At a finite time the radius would go to zero, so once the size of the window becomes of order 32 finest level cells, the box stops shrinking and the cloud finally appears to collapse. The dynamical time also decreases as the cloud shrinks, so in the following movie, the frame rate increases 10 fold and the collapse appears to proceed more slowly. This happens before the box stops shrinking (before the cloud appears to collapse).

movie​

I also restarted the run but with sink particle formation suppressed. The results are similar…

movie​

If the gradients in Phi are much larger then the gradients in pressure, then discretization errors in the potential can lead to large errors in pressure, which can lead to negative temperatures, and perhaps explosions?

The new criteria normalizes the potential by the sound speed squared and then looks at differences between adjacent cells. This is essentially \frac{\nabla \phi}{c_s^2} \times \Delta x > \mbox{TOL}

Also found a bug that caused particles to sometimes not accrete when they should. Explains why I was seeing zero-mass particles being occasionally created. I will check these in as soon as the code passes the suite of tests… In the meantime folks can pull from grassdata/johannjc/scrambler_1110007 if they are running simulations where accretion is expected to happen.

I updated the tests directory on Clover with the necessary reference chombos and bear2fix.data files for the tests that we currently have implemented. So, as Matt said yesterday, we are now prepared to run weekly tests in order to compare chombos and create images.

I also slightly updated the Test Suite page. The list of tests in the table now has everything that is in the test suite, and the ones we are currently working on including who is working on them.

Discussion of Senior Programmer Applicants.

Conferences.

Oral Examinations.

Research Discussion.

New Harris sheet test, magnetized clump simulations done. For images and animations, see the the project page (Scroll down to bottom).

​https://clover.pas.rochester.edu/trac/astrobear/wiki/AstroBearProjects/MagnetizedClumps

Test Suite Progress

The tests directory was updated and pushed into the development repository on Clover. See ehansen11042011. A makefile for alfalfa was created so that Matt's buildproblem script will work as is on that machine. The Orbiting Particles problem will also be added soon.

Approximate Riemann Solvers

I finished implementing an HLLC solver and a Roe solver into my hydro code. See my buildcode page for details. My next task in this area is to implement a Roe solver into astrobear.

Higher Order Schemes

I have just started my reading on higher order schemes. I plan on using the basic 1D MUSCL-Hancock scheme for my code. Is there a particular limited slope or slope limiter that I should use? Toro has a section on extending this scheme to higher dimensions as an unsplit finite volume scheme. I'm assuming this is the one we want for astrobear? Also, it is my understanding that astrobear already has routines to calculate slope limiters, so I won't have to code that part of the MUSCL scheme correct?

Today I talked with Jonathan about the sink implementation. Here are some notes on what I learned.

The calculation of forces are broken down into 4 types —

1) gas-on-gas (source/selfgravity.f90), 2) particle-on-gas (source/pointgravity.f90), 3) gas on particle (particle/paritcle_advance.f90), and 4) particle-on-particle (particle/particle_advance.f90)

Sinks have a 'point gravity' source term, and there is usually softening factors involved in calculating the gravity force (to avoid nans when the particle is at the center of a cell). The force is calculated from the gradient of the potential from the neighboring four cells. This can be seen in source_control.f90.

Once the forces are calculated, the motion of the particle is advanced. This is done by a 'leap frog' method, and is in particle_info_ops.f90. The 2 subroutines that control the particles motion/position are 'advance particles', and the 'accrete subroutine'.

In diagnosing and updating the sinks, it is best to begin by degugging the current algorithms. Then we will decide what parts of the alogorithm work and don't. Next, we will choose to add an additional accretion procedure (Bondi-Hoyle) to the code.

The tests directory in astrobear has been updated. It now contains 7 tests: Rayleigh-Taylor, Uniform Collapse, Field Loop Advection, a Field Loop restart test, and 3 Radiative Instability tests with different parameters.

So if you have properly set up your PATH to use Matt's buildproblem script, you can run (from the code directory):

buildproblem -t -np 4

This will compile and run all the aforementioned tests.

I'm on a roll today. The Roe Solver has been successfully implemented into my 1D Hydro code. As with the HLLC solver, I will not post all of the plots for the various tests. However, I did make a density plot for test 1 because there are some interesting things to note. I first ran the test without an entropy fix, and then ran it again with an entropy fix. Comparing those two plots is probably the most interesting thing you can do with the Roe solver. Again, you can see the plots on my buildcode page all the way at the bottom.

I have yet to add documentation to my buildcode page about the approximate solvers, but will do so in the near future. I do not plan on writing many details, but rather just a brief overview of the methodology behind each solver.

Now that I have an understanding of the Roe solver, I can start coding it into AstroBEAR. On second thought, this might be a bit more complicated. I will need to learn more about extending this to 3D and different equations of state.

So for now, I will start reading about higher order Godunov schemes to put into my hydro code.

I have successfully implemented an HLLC solver into my 1D hydro code. I decided to go with HLLC instead of HLL since it does a better job of resolving contacts. All the plots from the test runs are consistent with Toro. I posted the test 1 plot for density to show how the HLLC solver can actually sometimes do better than the exact solver. More specifically, it does a better job of resolving that entropy "glitch" inside the left rarefaction. The comparison plots are on my buildcode page at the very bottom.

I'm now working on a Roe solver, and after that is finished I will add some documentation about these two approximate solvers to my buildcode page.

I have updated the build problem script to the point where it is suitable for general use. To begin using on a regular basis, add the following to ~/.bashrc:

export PATH=/home/noyesma/bin:$PATH

The script now automatically dumps all chombo files to /data/tests/[MODULE]/out on clover.

This requires setting up passwordless SSH for your account. The procedure for this is a follows:

1. SSH into grass or alfalfa

ssh [username]@grass.pas.rochester.edu

2. Create a secure key

ssh-keygen -t dsa

DO NOT change the default name of id_dsa

When it prompts for a passphrase, just press press enter. This will make the key passphrase-less.

3. Change the private key permissions to be readable only by you.

chmod 600 .ssh/id_dsa

4. Install the public key on your remote computer (For clover, the home directory is the same as grass so you don't need to SCP it).

scp .ssh/id_dsa.pub [username]@clover.pas.rochester.edu
ssh [username]@clover.pas.rochester.edu
cat id_dsa.pub >> .ssh/authorized_keys
rm id_dsa.pub

I've been working trying to get Bondi Accretion to work successfully. Last time, the program bounced the gas falling in towards the center back out towards the edges. I tried to solve this problem by forcing the program to recalculate the momenta and density inside an inner radius and outside an outer radius to be constant. This, in effect, should take gas out of the center and inject gas into the edge of the grid.

I had some issues this week with getting computational units to work correctly- and I suspect that there may still be some issues in my module due to that, because I get obscenely small values for rho in my chombos. In the most recent test I've run, I've obtained these gifs:

​Radial Velocity
​Rho

So I think I figured out why the particles generated little bubbles when they are initially formed and it has to do with a missing factor of 2 in the force . At first I thought it was the way potentials were stored/updated. and what follows explains how to better do this, but the potential of a line charge is 2GM \ln(r) so the force is proportional to \frac{2GM}{r} not \frac{GM}{r}. And here is the explanation of how potentials are stored/updated…

When there are no sink particles, the gas potential \phi_{gas}, and it's time derivative \dot{\phi}_{gas} are used to interpolate the solution for \phi_{gas} at coarse fine boundaries. When a sink particle is formed the gas potential should respond to the missing material. The elliptic solver will make this adjustment provided that the boundary value for \phi_{gas} is correct. However this is problematic at the coarse fine boundaries since the value of \dot{\phi}_{gas} at the coarse fine boundary was prolongated from the parent grid pre-accretion. If instead of storing and using \dot{\phi}_{gas} at the coarse-fine boundaries, we use \dot{\phi}_{sink+gas} then this time derivative of the combined potential should be unchanged under the conversion of gas material to sink particles - however (and this is the tricky part), this is only true if both potentials use the same constant of integration… The elliptic solver normalizes the potential so that the sum is zero. However, the potential of a sink cylinder goes like ln(r) and cannot be conveniently normalized. One could calculate the integral of the potential over the entire box and subtract off the mean value analytically (or numerically), however if a multipole expansion is used instead then this becomes unecessary. A simpler normalization could be used for the potential. \log(r) => \log(r/a) where a is chosen so that the integral over the box of \log(r/a) is zero. For a circle of radius R_0, the constant a = R_0 e^{-\frac{1}{2}}. If we compare the potential of a particle at the center of the grid with an overdense cell at the center of the grid we see that there is fairly good agreement if we use R_0 = \sqrt{\frac{L_x L_y}{\pi}}

Here are two lineouts through the center of the grid with a particle and an overdense cell

And here is the same but with a softened particle potential

And here is the result if the particle is placed at [.125, .125]

And here is the full 2D image of the potentials

Not the periodic nature of the gas potential causes the turnover. Doing this with image particles is not generally feasible.

And here is the result of a simulation with the correct particle force. Click here​ for a movie.

I will talk about the various clump simulations I updated on the magnetized clump project page (scroll down to bottom for the update):

​https://clover.pas.rochester.edu/trac/astrobear/wiki/AstroBearProjects/MagnetizedClumps