export PYTHONPATH=/data/trac/astrobear/plugins:$PYTHONPATH; easy_install --install-dir /data/trac/astrobear/plugins tracmypageplugin/0.11/

Hello everyone,

According to the GNU General Public License guidelines every file in the AstroBEAR source code needs to contain "a copyright notice and a statement of copying permission, saying that the program is distributed under the terms of the GNU General Public License".

I have written a small script to insert a copying permission statement and a skeleton for a copyright notice in the source code, however, a decision is needed on what to write in the copyright notice.

There are three options:

1) Have a unified copyright notice as a collective

Copyright 1999 The AstroBEAR group

2) Have a unified notice and mention all the authors:

Copyright 1999 Terry Jones, Jonathan Doe, Eddie Smith, Erika Moore

3) Have an copyright skeleton in each file that the respective author would complete:

Copyright <YEAR> <AUTHOR>

for module Christina_Original:

Copyright 1999 Terry Jones

for module BasicDisk

Copyright 2003 Jonathan Doe

They should all be equivalent, it's just a matter of what the authors prefer.

I have been stepping through using the new refinement objects in the BE problem module. I added to the module both density gradient and Jeans threshold criteria for triggering refinement. I did so by following the steps on the page, RefinementObjects, and by just adding 2 calls sequentially in problem.f90.

The way Jeans based refinement is: each cell has associated with it a local Jeans length = Cs*Sqrt(Pi/G*rho). The refinement criteria for JeansLength is that if a cell's local JeansLength < 4*dx on a given level, than that cell is marked for refinement.

In my global.data file I set mx=16,16,16 and levels=7 with gtolerance=.10,.10,.10,.10,.10,1e30,1e30,.10 in an attempt to force the first 5 levels to be based on density gradients alone. If the collapse proceeded to make central cells jeans unstable, then the refinement based on threshold would happen on levels 6 and 7.

For the light ambient case, the refinement criteria worked well:

There was only ever 5 levels of refinement on the grid, Jeans threshold was not reached.

However, when checking the other case of a Matched ambient medium, the code would freeze or cause a segfault. Hmmm…. The only difference was the value of the ambient rho. Since the code was freezing at grid 3 initialization, I had a feeling the entire mesh was being refined. Since I was simply raising the ambient density by a constant everywhere, it did not make sense this would be due to density gradients. So I computed the Jeans' length for ambient cells in Visit: (<SoundSpeedScaled>*sqrt(pi/(ScaleGrav*rho))) = 3.648 in ambient. Compare now to 4*dx=4*(15.4/16)=3.85, ah, Jeanslength is slightly smaller. So, sure, there is refinement expected in the ambient.

The interesting thing I noticed next was that, contrary to what I'd expect, I was unable to de-trigger this refinement. I added more cells to the root level, which would mean smaller dx, and so no Jeans refinement right? Well, that did not happen. Not even with 22 cells! So. Why freezing at level 3? I restarted a sim with 2 AMR levels, and checked the output. Sure enough, the ambient was refined, and not just to the 1st level, but to the max level. No wonder the code was causing a segfault on BH with 7 levels! So. A movie of the Jean's length and the mesh than revealed the next interesting thing:

​http://www.pas.rochester.edu/~erica/weirdness1.gif

This ring is maybe due to density falling in to the sphere in a compression wave? Well, it wasn't, rho was constant out there. But Jeans is a function of Cs, and Temp as well, and so a movie of that revealed this:

​http://www.pas.rochester.edu/~erica/2weirdness.gif

Yikes.

I am not making a ticket yet, as I am not entirely sure if this is a problem. For one, the color bar indicates that the temp is indeed constant in the ambient, as it should be for this 'isothermal' sim., so maybe this is a visualization artifact? And 2, I may have been mistaken on how the new grids are laid down for the threshold based refinement. Is it setup to refine maximally when the Jeans Threshold is reached?

The ambient is light, 1/100 of rho(Rbe).

​http://www.pas.rochester.edu/~erica/stabilityCheck.gif

This was just an octant simulation, using reflecting boundary conditions with self-gravity

Here is a movie of the lineout for rho:

​http://www.pas.rochester.edu/~erica/lineoutStabilityCheck.gif

AGN jet/Stellar wind interaction. I have new data from 2 runs: weak and strong jet. The stellar wind now has a mass loss rate of 10^-4M_sun/yr and it goes off at the jet's axis. The wind lasts for 10kyr only, and after that I stop injecting it.

Jet tracer maps. It's a time sequence (bottom of each map) from left to right. Next to each other you see the with-star vs. the without-star sims, left and right, resp. You can see that the effect of ONE star on the jet lasts for 40kyr.
The same is true for the kinetic energy: snapshot at 30kyr after the star was ejecting its wind.

The effect is much milder when the AGN jet is stronger. This is a logarithmic density map with overlaid jet tracer contours.

Here is the plot of beta for my 1D MHD radiative shock. I also put density on the same plot, and some constant lines to show where beta = 1.0. So you can see that the density increase starts to slow down when beta goes to 1.0. But I would say that the density profile does not go relatively flat until a lower beta (approx. 0.4 or so).

• Golden Version
  1. Test passed on grass, alfalfa and bamboo with the modules we have
  2. Still miss three modules: IonizationTest, Rotating Collapse

• XSEDE Allocation
  1. Approved but not way more less: Resource Name NICS Cray XT5 (Kraken) Resource Requested Amount 4000000 Resource Awarded Amount 1138234 Resource Name TACC Sun Constellation Cluster (Ranger) Resource Requested Amount 4000000 Resource Awarded Amount 1326290

• Upate to the local machines
  1. New OS up
  2. Will discuss with Rich about updating trac and re-installing Wiki plugins

• Blue Gene Q
  1. will attend piloting user meeting this afternoon

• Tickets:
  1. closed: #236, #237, #238 (Golden version)
  2. New: #251 (wiki update), #252 (Self-gravity restart), #253 (automatic testing run)

• Yat Tien's visit
  1. Thank everybody's work for the training
  2. Returned the keys
  3. Emailed Rich to delete the account

1D MHD Radiative Shocks

The MHD version of my RadShock problem appears to be working, but I am not sure if the output is physically accurate. Red is hydro, blue is MHD.

I am now waiting for Anna (Pat's student) to send me her data so I can compare these MHD runs. I will also be comparing the emission lines.

Post-Processing Emissions

I finished implementing some emission lines into astrobear's post-processing routines. We now have the capability to get [O I] (6300), [N II] (6583), [S II] (6716), [S II] (6731), and H-alpha. Other lines for these species could easily be added, and we also have code for [O II] and [N I] if we want to be able to use those species in the future. Here's an example of what the output looks like for one of my 1D radiative shocks (hydro):

Jonathan also changed a few things in astrobear's post-processing routines, and I updated a bunch of problem modules to conform with these changes. Since AstroBEAR 2.0 is about to be released, I guess we would want this stuff in our new development version (aka AstroBEAR 3.0)?

3D Cooling Jets

Moderate cooling run resubmitted on Kraken, should finish this week. Not sure if we can get the resolution needed for the strong cooling case…

Mach Stems

I will start working on this project tomorrow.

Nora Rose Carroll-Nellenback

Born September 21, 2012

weighing 11 lb 7 oz

HSE:

• Had a few HSE configurations to be stable over time ​link
  
• Now we are testing the code with a more realistic density and pressure profile ​link
  

AstroBEAR improvements:

• Started working on ticket ​250

Implemented multiphysics: resistivity, conductivity, viscosity.
The switches are in physics.data:

Gaussian profile heat conduction test Initial condition: gaussian temperature profile, magnetic field is on the diagonal direction. The mhd heat conduction is turned on.
In the following figure (density), top left is single processor fixed grid, bottom left is 8 processors fixed grid, top right is 8 processors AMR.

Petschek reconnection test The following figure shows the Petschek shock from a reconnection spot at the center. Colored variable is the kinetic energy in log scale, magnetic field is illustrated by white lines.

See a movie here:
​http://www.pas.rochester.edu/~shuleli/multi_test/sp1.gif

There is a bug in AMR case. See the following figure, colored is kinetic energy. You can see instabilities at the corner of inner boundaries.

KH instability with Braginskii viscocity. Please refer to a previous post of mine for the images.

Multiphysics is interlaced. Depending on total number of steps(maxlevel) you have taken, the code shuffles the order of calls to resistivity, conductivity and viscosity. Multiple component: tested conduction + resistivity and conduction + viscosity. Both ran well.

Potential tests for multiphysics.
Conduction: MTI, Parker instability
Resistivity: Hartman flow, Petschek reconnection
Viscosity: Hartman flow, MRI

New generic data transfer interface. This will be used for anything involving subcycling AMR. Explicit solvers mentioned above and their implicit versions will be using this new interface to speed up multiphysics calculation. Currently the implementation is near finished, but I haven't got time to debug or test it. Will be the emphasis for the next few weeks and the next release.

Papers. Clump Paper: Submitted to ApJ. Resistive paper: waiting for the last two runs to finish.

This week. Fix bugs, test more on multiple components, merge the code (this version is my own version of 1020, derived from 1010 main repo), start writing the resistivity paper draft, start writing the qual brief.

Last week was largely slow due to various issues with Grass. I worked with Rich a lot to get Grass up and going again. Of the few bugs we fixed, we are now running Visit 2.5 which is not stalling anymore. Not all of the kinks are worked out, but at least grass is functioning now.

I compiled a reading list for myself of a few textbooks and papers last week and began reading. I am pretty excited about these 3 papers I found on adsabs:

• Foster, Prudence N.; Boss, Alan P., Triggering Star Formation with Stellar Ejecta: "We examine inducing the self-gravitational collapse of molecular cloud cores with stellar ejecta. We study the effect of winds of various strengths arriving at cloud cores modeled as marginally stable Bonnor-Ebert spheres, which are unstable both to collapse and to expansion. We find that some winds instigate collapse of the cloud core, while others result in expansion or destruction of the cloud. Collapse occurs when the incident momentum of the ejecta is greater than approximately 0.1 MMsun0 km s-1 for the standard γ = 1 wind and 1 Msun cloud scenario. The critical momentum, which divides those cases which induce collapse and those which do not, scales as the mass of the cloud times its sound speed, which is 0.2 MMsun0 km s-1 for the standard to K cloud. The critical momentum is exceeded for some supernova and many protostellar outflows, although if the wind has a velocity greater than approximately 100 km s-1, the effective adiabatic index will be γ = 5/3 and the cloud will be destroyed, through shredding into many pieces. The planetary nebulae of AGB stars appear to have momenta below the critical value. However, we found that a high wind temperature (T ˜600 K), possibly characteristic of AGB star winds, could instigate collapse even in low momentum winds." ​http://adsabs.harvard.edu/abs/1996ApJ...468..784F

• "Formation and collapse of quiescent cloud cores induced by dynamic compressions" Gómez, Gilberto C.; Vázquez-Semadeni, Enrique; Shadmehri, Mohsen; Ballesteros-Paredes, Javier, ​http://adsabs.harvard.edu/abs/2007ApJ...669.1042G

• "Radiation hydrodynamics of triggered star formation: the effect of the diffuse radiation field". Haworth, Thomas J.; Harries, Tim J., ​http://adsabs.harvard.edu/abs/2012MNRAS.420..562H, "We investigate the effect of including diffuse field radiation when modelling the radiatively driven implosion of a Bonnor-Ebert sphere (BES). Radiation-hydrodynamical calculations are performed by using operator splitting to combine Monte Carlo photoionization with grid-based Eulerian hydrodynamics that includes self-gravity. It is found that the diffuse field has a significant effect on the nature of radiatively driven collapse which is strongly coupled to the strength of the driving shock that is established before impacting the BES. This can result in either slower or more rapid star formation than expected using the on-the-spot approximation depending on the distance of the BES from the source object. As well as directly compressing the BES, stronger shocks increase the thickness and density in the shell of accumulated material, which leads to short, strong, photoevaporative ejections that reinforce the compression whenever it slows. This happens particularly effectively when the diffuse field is included as rocket motion is induced over a larger area of the shell surface. The formation and evolution of 'elephant trunks' via instability is also found to vary significantly when the diffuse field is included. Since the perturbations that seed instabilities are smeared out elephant trunks form less readily and, once formed, are exposed to enhanced thermal compression."

Last week got code up and running on grass and BH. I re-ran a stability check on the B&P sphere for 5 crossing times. I wasn't able to make a movie over my remote connection, for an error I don't yet understand:

-visit is waiting for a cli to launch on local host VisIt could not connect to the new client /usr/local/alt/visit2_5_0.linux-x86_64/bin/visit

But, the sphere did appear to be stable. It oscillated about its equilibrium, although it expanded much more than condensed. Not sure if this is significant or unexpected…

Next, wanted to tidy up the runs I worked on over the summer, by adding more sophisticated refinement criteria, and running out until a sink formed. I learned about the refinement objects and added the 2 criteria to my problem module: 1) refine on density gradients, and 2) refine on Jean's threshold. I didn't see any apparent conflict in the code that would prevent multiple flags to be called… is this the case?

When I tried to run the B&P matched case, however, the code froze on grass after initialing only the first 3/5 grids. It just stopped printing lines, although top showed it was still computing… I tried it in the debug queue on BH, but it seg-faulted. Not entirely sure why changing the ambient density from very light to heavy would change the computation, other than the Jean's refinement may be triggered and the entire domain is being refined. The way my data file was set up though, I thought would restrict Jeans based refinement to happen only for higher levels. . .

Lastly, I wanted to check before running large sims if restarts with self-gravity are working okay with the golden version. It seems though, that there is a bug with them (posted a ticket). This makes long jobs a little risky to run. .

• 3D Cooling Jets - I tested my weak cooling run on alfalfa (8 procs) and bluegene (256 procs). Bluegene should be significantly faster, but for whatever reason it runs less efficiently. I moved to Kraken and ran the moderate cooling case. This run is also fairly inefficient (35%), but since I can use so many procs (4092) it ran halfway in 17 hours. Not sure why it did not run for the full 24 hours. I have not had a chance to visualize the data yet. So it looks like I should be able to finish this on Kraken, but the strong cooling case will probably not be possible at 10 cells per cooling length.

• Line Emissions - I started coding the routines required for emissions post-processing. I am essentially taking the code from bear2fix and putting it into astrobear's processing routines. I have most of the infrastructure set up, and I will be testing SII with my RadShock module. After I have coded everything we will be able to get synthetic observations for OI, OII, NI, NII, SII, and H-alpha.

• MHD RadShock - This is already coded into my RadShock module, so now I just need to test it.

• Mach Stems - A new project that Adam, Pat, Kris and I talked about last week. With all my other things going on, I am guessing that I will not even get started on this until sometime next week.

HSE, stage 1:

• Astrobear now calculates the pressure needed for HSE using a discrete method (cell by cell)
• HSE code does not need to be changed for new density profiles
• Custom density based on star models needs to be loaded (that's where we are at now ..)

HSE movie example:

• Very low velocities
• Reflected boundaries
• Very small or no change in pressure profile, over a timescale of 4 disk rotations (the disk we used to have in the previous simulations)
• Not a final demonstration of HSE since density profile is not consistent with a star model
• It's simply a test
  

​HSE-test

• Golden Version Status
  1. Merged with everyone's code, current testing status ​https://clover.pas.rochester.edu/trac/astrobear/wiki/u/MyCurentTests
  2. Jonathan modified the test-running script so testing result will be sent to an individual folder instead of a comment current test folder
  3. Modules needed more work:

BE_stuff	does not pass test Updated wiki page linked to the testing page
BasicDisk	Updated page linked to the testing page
MomentumConservation	Updated page linked to the testing page
MultiClumps	About 17 mins on 8 cores of alfalfa Updated page linked to the testing page
SingleClump	does not pass test Updated page linked to the testing page
SlowMolecularCloudFormation	Updated page linked to the testing page
ThermalInstability	Updated page linked to the testing page

4. Makefile.inc files for local machines need to be double-checked
5. Missed the testing page on wiki

• Yat Tien's visit
  1. Followed the training schedule
  2. Will install astrobear on a UCLA machine so he has a machine to use when he leave here.

• Request to restart our local workstations
  1. Start using Ubuntu Linux 12.04 instead of the older version 10.04
  2. Deadline Friday Sep 21
  3. Planning to set up a time to restart all of them with Rich present

• New Tickets
  1. #248 (Unified nomenclature) — completed
  2. #249 (Isotropic turbulence has an empty global.data) —fixed

• Two new paper from Martin on publication page:
  1. ​https://clover.pas.rochester.edu/trac/astrobear/wiki/AstroBearPublication

• Blue Streak (the Q)
  1. Installed AstroBEAR. Got a data file open/read problem when running — could related to the file system.

• Teragrid Proposal — No news
  1. the review starts on Sep 1st And the allocation should begin on Oct. 1 if got approved.

I modified the buildproblem script and currenttests plugin to use your username in the various paths. This will prevent multiple users from stepping on each other's toes. To see your current test output you need to create a page (or somewhere on your personal page) that has the following text…

CurrentTests(johannjc, 250px)

(where johannjc is replaced with your username)

Of course this won't work until you've updated your buildproblem script but that should be in the main repo soon…

Disks. Status of the paper?

AGN jet truncation. Progress on the poster. New sims look more realistic and are half way done:

Here you see the star half way though the jet's beam (red). The star's wind injection radius is about .125-.25 jet radii (it was ~1 jet radius before). Cocoon material is blue. This is a logarithmic color map of the jet's tracer field.

Here's a log dens movie of the sim: ​http://www.pas.rochester.edu/~martinhe/2012/17sep12.gif

Waiting for Andrea and Bruce to respond for the wind collimation and CRL 618 projects.

I did some research regarding what option to choose for a license. First, I looked at a few MHD codes that are freely downloadable, 70% of them are released under GPL v2/v3 license, the rest have a BSD or MIT license, and some come with no license at all.

Below is a simple as possible explanation of the 3 most used licenses, GPL, BSD and MIT

GPL is the open source license that seems to give the most restrictions, here is an except of a simple explanation that I've found online

• The GPL governs ones rights to redistribute software using the GPL as a license.

• The GPL gives me the right to take GPL code and redistribute it as is (provided that I also respect any related trademarks). For example, I can't take Firefox and redistribute it under the name "Firefox" since the name is a trademark owned by Mozilla and only they have the right to convey its name on software.

• the GPL also allows people to sell copies of GPL software. Most people don't understand this for one simple reason, "why buy the cow when I can get the milk for free." Selling GPL software just doesn't make sense in that regard. But it has been done very successfully. People used to sell Linux on CD - but the value of doing so was clear: at the time to download Linux could take days, so for many shelling out $29.95 for the 5 of so CDs was a huge convenience.

• The GPL also says that you can take GPL software, and modify it and redistribute it as well. For example, Microsoft could take the OpenOffice suite, make tons of changes (under auspices of making it better) and then turn right around and sell it. —- There is a catch though, any change you make to GPL software AND also redistribute you must also make available under the same license. In other words, Microsoft would need to make any changes they made to Open Office freely available to others.

• The GPL also says I can take a portion of code from a GPL program and include it in my own. For example, say I want to write a blogging platform in Perl. I have written most of the code myself, but I deem Movable Type's commenting system to be perfect. So I cut and paste large portions of it into my software. Under the GPL, this is equivalent to forming a derived work, and my new blogging platform is compelled to be GPL as well.

Please note this part:

• with GPL it is reasonable and acceptable for someone to download a copy of WordPress, modify it, pay a consultant to modify it, add features to it, redesign it, etc, etc, etc. and never be compelled to share the modifications they have made, or be compelled to open source anything else in their organization.'

Moving on, the BSD license is less restrictive.
Here is a quote I found: If you want to give your software away for free, use BSD. If you want to share your software, use the GPL.
This license allows other entities to redistribute a software without releasing the source code. It provides a very short license agreement:

1) Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3) Neither the name of Yahoo! Inc. nor the names of YUI's contributors may be used to endorse or promote products derived from this software without specific prior written permission of Yahoo! Inc.

Last but not least, we have the MIT license, it gives the same restrictions as a BSD license, the only difference is that an MIT license does not force other entities to mention the original authors of a software in case of redistribution.

A useful comparison table ( ​https://blogs.oracle.com/davidleetodd/entry/free_and_open_source_license )

I've been trying to use Jonathan's new refinement object in the 3D cooling jet sims. It's set up so that a refinement shape (in my case a rectangular prism) moves across the grid at a certain speed. Everywhere inside this shape is refined. The shape moves at roughly the same speed as the head of the jet, so that the head of the jet is always refined. However, based on what I see from the mesh in visit, the sim is not always refining everywhere within my shape.

Here are the relevant movies:

rho.gif​

rho_mesh.gif​

I've also tried turning on gradient based refinement within the shape but this looks even worse:

rho_gradmesh.gif​

UPDATE

Sorry, the above movies were sliced at the wrong spot. Here is what they should look like:

These updated movies are on a log scale.

I installed a new macro called redirect which is very convenient for setting up redirect pages. You just put this at the top of a wiki page:

[[redirect(OtherWikiPage)]]

So when you try to access that wiki page you'll be redirected to OtherWikiPage.

I mainly wanted this for the AstroBearTesting page. If you recall, Jonathan had updated the Tests macro to display links to each test's wiki page. This link is based on the test's name, so for example the link for the FieldLoopAdvection test takes you to TestSuite/FieldLoopAdvection. However, this test also has a restart test which is called FieldLoopRestart. FieldLoopRestart does not have its own test page on the wiki so if you click on TestSuite/FieldLoopRestart you just get redirected to the FieldLoopAdvection test page.

This will be helpful for other tests that have multiple versions but just one test page.

HSE:

• Jason will be reviewing calculations done so far

AstroBEAR enhancements:

• Working on ticket ​#248

• AGN jet truncation. Running the simulations and preparing the poster for the Italy conference. The wind radius that we used in the last runs was too large to be realistic, but they gave us some data to work with. I'm now running sims which will likely be production runs.

• Magnetic collimation of spherical winds. Andrea and I will have a phone call meeting early this week to discus future runs on this project.

• Sent HEDLA proceedings to arxiv and updated title of the magnetic tower paper.

• Writing research proposals for job applications.

Worked with Shule and Ivan on code implementation and prepped for journal club. Left for wedding on Friday

What I've been doing:

Bx, By runs with R# = inf, 1000, 100 (the same as I posted last week, just twice the framerate) are almost finished. The only one unfinished is the Bx R#=100 run currently at 80% progress.

The Hydro run for the resistive paper is finished.

Implementing Subcycling and persistent communication mechanism for Astrobear 2.0

Finished 9 out of 11 test modules.

Finished the color version of the ApJ clump paper. Ready to submit. I still have to make low resolution version to submit to astro-ph though.

Revising the HEDLA proceeding paper. Probably will get it done this week.

• Golden Version Status:
  1. Progress: ​https://clover.pas.rochester.edu/trac/astrobear/wiki/GoldenVersion
  2. Merging with Eddie and Shule's code.

• Tickets:
  1. Closed: #225, #242

• Schedule for Yat-Tien's visit
  1. ​http://www.pas.rochester.edu/~bliu/Yat_Tien_UCLA/YatTienLee_Schedule.pdf

• Completed test modules and documentation for:
  • Filling Fraction
  • Marquee
  • Isotropic Turbulence
  • Gravitational Cascade
  • Molecular Cloud Formation
• Updated Matt's tests macro plugin to show links to test descriptions (see AstroBearTesting)

• Golden Version Status:
  1. Progress: ​https://clover.pas.rochester.edu/trac/astrobear/wiki/GoldenVersion
  2. Merged Testing Modules from Baowei and Jonathan. All test passed. Checked into the main repo: ​https://clover.pas.rochester.edu/trac/astrobear/wiki/u/bliu#no1
  3. Will try to do the first merging-all late this week or early next week

• Tickets
  1. New Ticket: #246 (update wiki page for data files: ​https://clover.pas.rochester.edu/trac/astrobear/wiki/DataFileTutorial)
  2. Reopened Ticket: #240 (Segmentation fault on Kure) — description modified, reassign to Jonathan
  3. Closed ticket: #244

• astro-sim.org
  1. Martin sent Steffen Brinkman the webmaster an email as they know each other.

• Worked on:
  1. #237 Merging with Jonathan's testing modules
  2. #240 re-run with the attached problem.f90 on alfalfa
  3. #244 Segmentation fault running Uniform Collapse testing module, fixed
  4. #245 Installing libs for AstroBEAR on Blue Streak: Currently get trouble installing parallel version hdf5.

• Finished the Disk module tutorial (it needs to be linked somewhere)
• Done with orientation (Ivan)
• Resumed work on HSE today

• Disks. Any news on the paper plan?,

• Teragrid large proposal. No news from them yet,

• AGN jet truncation. Got all conference travel arrangements done, working on the poster

(​http://www.pas.rochester.edu/~martinhe/2012/AGNposter.pdf) and running the sims.

Seems I need reruns with smaller RG wind radii, see ​http://www.pas.rochester.edu/~martinhe/2012/4sep12.gif, where I show 3 planes perpendicular to the RG orbital trajectory to follow the RG mass-loading on the jet.

• Mag. tower paper. Solved all publishing matters, so it's is press now,

• Spherical wind collimation via a uniform mag. field (Ciardi). Last run (​http://www.pas.rochester.edu/~martinhe/2012/andrea6aug12.gif) was not cooling. Running a cooling version of it at Bgene now:

​http://www.pas.rochester.edu/~martinhe/2012/5sep12.gif

Will email Andrea once I get the data,

• Colloquium at AI-UNAM. Went really well, got good feedback, a potential permanent position for the future and this interesting reference on non-magnetized jet launch models: ​http://adsabs.harvard.edu/abs/2011arXiv1103.0250H.

1. Link and build your problem module.
2. Modifying the data files to follow the format of those in Template
3. Adjust the number of frames to 1 and the final time to be something small so that the run completes in under 1 or 2 minutes (optimized)
4. make a ref directory parallel to the out directory and copy over chombo00001.hdf
5. make a logs directory
6. make an images directory
7. Run bear2fix and select operations to make a nice image that can be used to verify the solution is 'correct'
8. run ../../bear2fix/ps2png.pl out/pgout00001.ps
9. mv out/pgout00001.png images/ref.png
10. Now rerun the same code with a different number of processors and pipe the output to logs/testlog
11. Rerun bear2fix in batch mode to produce another image for this run
12. run ../../bear2fix/ps2png.pl out/pgout00001.ps
13. mv out/pgout00001.png images/sim.png
14. mv bear2fix.data bear2fix.data.img
15. Run bear2fix and select operation 10
16. mv bear2fix.data bear2fix.data.test
17. mv out/chombo00001.hdf logs/sim.hdf
18. cp max_errors.data to the ref directory and mv max_errors.data mean_errors.data and max_rel_errors.data to the logs directory
19. add bear2fix.data.img and bear2fix.data.test to the mercurial repository (hg add bear2fix.data.img bear2fix.data.test)
20. Now navigate back up to the code base directory and add your problem module to the list of problems defined near the top of /scrambler/buildproblem. Add it to the front of the list for faster debugging!
21. Commit the new file additions and the modification of buildproblem to the repo.
22. Now you will want to use svn to check out a new version of the test repo. svn co ​file:///cloverdata/repositories/tests ~/tests
23. Create a directory for your problem module in the test repo parallel to Bondi, etc…
24. Navigate into your newly created directory and move the logs, images, and ref directory from your code directory
25. Now add your test problem directory to the svn repo using svn add MolecularCloudFormation (or whatever yours is called)
26. Now we can commit those additions to the svn repo. svn ci -m 'added my problem module'
27. Now you need to let the trac test macro know about the new module directory. So log on to clover and go to /data/tests and run svn update and then run trac-admin /data/trac/astrobear changeset added tests N where N is the revision number you just updated to.
28. At this point you should be able to go to the test page on the wiki and see your sample test results ​https://clover.pas.rochester.edu/trac/astrobear/wiki/AstroBearTesting
29. Now go back to your code directory and run buildproblem -np 8 -t to start the problem testing
30. If this passes then you are all set to check in your mercurial repo! If not then seek help
31. Don't forget to add your problem module to ​https://clover.pas.rochester.edu/trac/astrobear/wiki/TestSuite
32. And then create a page for your module using the TestTemplate template