• Modification to the code: Merged everybody's work. A Good Starting Point for our golden version
  ​https://clover.pas.rochester.edu/trac/astrobear/log/Scrambler/?action=stop_on_copy&mode=stop_on_copy&rev=af45abad226a79da4317e74180e992b28a8f7524&stop_rev=b789b34104cb&limit=200

• New Tickets for Testing Modules: #232, #233, #234, #235, #236, #237, #238

• Worked on #202, #231, #232

Disks

• 15 AU run up to 2.5 orbits. Consisten results with the 10 and 20 AU sims, however, for some reason that I have yet to understand, the Disk mass and particle accretion profiles show more variations than the other two cases:

	Disk mass
	particle accretion

• paper. Added more and info and still writing the results and intro sections, see updated DRAFT at ​http://www.pas.rochester.edu/~martinhe/2012/binary/paper.pdf

-AGN jet truncation. Sims showing quite a bit of protections which lead to jet asymmetries. Working on solving this.

On Tuesday, Jonathan, Eddie and I had a little discussion about the project management of our code—especially after we have our golden version. I played with some of the ideas with these Mercurial extensions: branches, tags, graphic log view and transplant. The following summarized some of my tries.

Introduction to Our new Mercurial tools

1. hg branch: create a branch under the same repository and check with branch you are working with. Users can specify which branch he/she wants to pull the code from
2. hg tag: attach a tag to a revision. will create a new revision. Seems cannot attach a tag to individual files.
3. hg glog or hg view: view the whole developing tree/revision structure
4. hg transplant: cherry-picking the code

Schemes of Project Management

According to Karl Fogel's book which can be found at ​http://producingoss.com/. Especially Chapter 7 - Packaging, Release and Daily Development; The Release Branches Section, I think two branches work better than one and taking a snapshot of the tree is not a good way to get a stable version. Two branches can balance well on checking in the developer's effort as soon as possible and lowering the risk of checking in controversial/unstable code.

• Default branch/trunk: for development mainline, every developer can check in his/her code as long as it passes our NEW strong testing suite.

• A Release Candidate Branch: only check in clean and ready code (including bug fixing) which means
  1. Pass our NEW strong testing suite
  2. No controversial opinions from other developers
  3. All developers agree on checking to that release.

• Developers should update his/code developing branch frequently to the trunk — several times a day according to Karl Fogel.

We can have more branches like branches for release 1.0 and release 2.0. And with Mercurial-transplant, bug-fixing for 1.0 only can be cherry picked from the trunk to 1.0 branch only (Examples shown below).

My originally thinking was to create a branch under the same repository for each developer. The with hg glog or hg view, the developing tree of our whole group can be easily seen. But one thing, this tree could be very complicated. And people could easily get confused which branch he/she is working on (See the example for Scheme I).

The second thing I tried was to make two branches under the same repo. This was basically Jonathan's idea. Though the check-in procedures of the two branches were based on what I mentioned above, which was different from Jonathan's way. This scheme worked OK. The tree could be messed up a bit when I made mistake cherry-picking code. (revision 15 in the example for Scheme II)

The third scheme I tried was to have two branches in two repos: one for developing, one for release — could have more if we have more release candidates. This one we had much clear, separate and different though, tree structures for the two branches. cherry-picking was easier. I did make a mistake cherry-picking the code when I tried, but it didn't show in the developing tree (See the example for Scheme III).

Both the latter two are used in open source software project management according to Karl Fogel. And all three schemes can be realized with Mercurial.

• Scheme 1
  

o    changeset:   14:7e05196f1647
|\   tag:         tip
| |  parent:      12:d07c7f335631
| |  parent:      13:567d336f6d7a
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 13:23:44 2012 -0400
| |  summary:     Shule merge his branch to trunk
| |
| o  changeset:   13:567d336f6d7a
| |  branch:      shule
| |  parent:      11:5935bfa52647
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 13:22:27 2012 -0400
| |  summary:     shule added feature 2
| |
o |  changeset:   12:d07c7f335631
|\|  parent:      7:75d40ef53d13
| |  parent:      11:5935bfa52647
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 13:19:05 2012 -0400
| |  summary:     Shule merged his branch with trunk/developing branch
| |
| o  changeset:   11:5935bfa52647
| |  branch:      shule
| |  parent:      8:ec480f53ab7f
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 13:16:57 2012 -0400
| |  summary:     created module 2 by shule
| |
| | o  changeset:   10:c160040af250
| | |  branch:      1.0.x
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 13:14:18 2012 -0400
| | |  summary:     Added tag RELEASE_1_0_X for changeset f37e3dfa00ff
| | |
+---o  changeset:   9:f37e3dfa00ff
| |    branch:      1.0.x
| |    tag:         RELEASE_1_0_X
| |    parent:      7:75d40ef53d13
| |    user:        bliu <bliu@pas.rochester.edu>
| |    date:        Thu Jul 26 12:06:15 2012 -0400
| |    summary:     Created branch for release 1.0
| |
| o  changeset:   8:ec480f53ab7f
|/|  branch:      shule
| |  parent:      3:ffed79d15d20
| |  parent:      7:75d40ef53d13
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 12:00:14 2012 -0400
| |  summary:     Shule merged with the developing/default branch
| |
o |    changeset:   7:75d40ef53d13
|\ \   parent:      4:ecfeaa2d72e6
| | |  parent:      6:61b0ac6b5c20
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 11:56:58 2012 -0400
| | |  summary:     Eddie merged feature 1 to the developing/default branch
| | |
| @ |  changeset:   6:61b0ac6b5c20
| | |  branch:      eddie
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 11:55:17 2012 -0400
| | |  summary:     Eddie added feature1
| | |
| o |  changeset:   5:55e842fae920
|/| |  branch:      eddie
| | |  parent:      2:0fb3775dcc73
| | |  parent:      4:ecfeaa2d72e6
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 11:41:25 2012 -0400
| | |  summary:     Eddie merged with the developing/default branch
| | |
o---+  changeset:   4:ecfeaa2d72e6
| | |  parent:      0:c70162535253
| | |  parent:      3:ffed79d15d20
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 11:35:16 2012 -0400
| | |  summary:     Merged with Shule's branch
| | |
| | o  changeset:   3:ffed79d15d20
| | |  branch:      shule
| | |  parent:      1:d145928ca80e
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 11:31:06 2012 -0400
| | |  summary:     Shule's 1st modification to Module 1
| | |
| o |  changeset:   2:0fb3775dcc73
|/ /   branch:      eddie
| |    parent:      0:c70162535253
| |    user:        bliu <bliu@pas.rochester.edu>
| |    date:        Thu Jul 26 11:26:57 2012 -0400
| |    summary:     Created Branch for Eddie
| |
| o  changeset:   1:d145928ca80e
|/   branch:      shule
|    user:        bliu <bliu@pas.rochester.edu>
|    date:        Thu Jul 26 11:26:28 2012 -0400
|    summary:     Created Branch for Shule
|
o  changeset:   0:c70162535253
   user:        bliu <bliu@pas.rochester.edu>
   date:        Thu Jul 26 11:25:49 2012 -0400
   summary:     Initial commit of TAstroBEAR

• Scheme II
  

@    changeset:   19:c687cd2b699d
|\   branch:      1.0.X
| |  tag:         tip
| |  parent:      16:3d2c4134f5e6
| |  parent:      17:b8e25dc8c496
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 16:32:18 2012 -0400
| |  summary:     Eddie fixed a bug in module 1
| |
| | o  changeset:   18:d95fe8c2bae7
| |/|  parent:      17:b8e25dc8c496
| | |  parent:      13:250de7722735
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 17:36:04 2012 -0400
| | |  summary:     Eddie merged his branch with bugfixing in module 1 with trunk
| | |
| o |  changeset:   17:b8e25dc8c496
| | |  parent:      11:257c587657ca
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 16:32:18 2012 -0400
| | |  summary:     Eddie fixed a bug in module 1
| | |
o---+  changeset:   16:3d2c4134f5e6
| | |  branch:      1.0.X
| | |  parent:      15:750c823af31f
| | |  parent:      13:250de7722735
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 16:37:23 2012 -0400
| | |  summary:     Shule fixed a bug in feature 1
| | |
o | |  changeset:   15:750c823af31f
| | |  branch:      1.0.X
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 17:22:19 2012 -0400
| | |  summary:     backout the mis cherrypicking from the default branch
| | |
o | |  changeset:   14:c8d8de75b020
| | |  branch:      1.0.X
| | |  parent:      12:0b29e0bacf7d
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 15:33:31 2012 -0400
| | |  summary:     Eddie modified the feature1.f90
| | |
| | o  changeset:   13:250de7722735
| |/   parent:      11:257c587657ca
| |    user:        bliu <bliu@pas.rochester.edu>
| |    date:        Thu Jul 26 16:37:23 2012 -0400
| |    summary:     Shule fixed a bug in feature 1
| |
o |  changeset:   12:0b29e0bacf7d
| |  branch:      1.0.X
| |  parent:      6:cd151c2100ad
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 16:30:23 2012 -0400
| |  summary:     Eddie modified feature 1
| |
| o    changeset:   11:257c587657ca
| |\   parent:      10:a22779a560a7
| | |  parent:      9:ae21e6d2d4ba
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 15:43:15 2012 -0400
| | |  summary:     Eddie merge his branch with the main branch
| | |
| | o  changeset:   10:a22779a560a7
| | |  parent:      7:cf843a15dbf1
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 15:33:31 2012 -0400
| | |  summary:     Eddie modified the feature1.f90
| | |
| o |  changeset:   9:ae21e6d2d4ba
| |\|  parent:      8:94bdb895f471
| | |  parent:      7:cf843a15dbf1
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 15:39:53 2012 -0400
| | |  summary:     merged after putting the tag RELEASE_2_0_X
| | |
| o |  changeset:   8:94bdb895f471
| | |  parent:      4:46982b65c965
| | |  user:        bliu <bliu@pas.rochester.edu>
| | |  date:        Thu Jul 26 15:30:45 2012 -0400
| | |  summary:     Added tag module2.f90, RELEASE_2_0_X for changeset 46982b65c965
| | |
| | o  changeset:   7:cf843a15dbf1
| |/   parent:      4:46982b65c965
| |    user:        bliu <bliu@pas.rochester.edu>
| |    date:        Thu Jul 26 15:08:58 2012 -0400
| |    summary:     Shule created module 2
| |
o |  changeset:   6:cd151c2100ad
| |  branch:      1.0.X
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 15:04:21 2012 -0400
| |  summary:     Added tag RELEASE_1_0_X for changeset 115372a64138
| |
o |  changeset:   5:115372a64138
|/   branch:      1.0.X
|    tag:         RELEASE_1_0_X
|    user:        bliu <bliu@pas.rochester.edu>
|    date:        Thu Jul 26 15:03:31 2012 -0400
|    summary:     created a branch for 1.0.X
|
o    changeset:   4:46982b65c965
|\   tag:         RELEASE_2_0_X
| |  tag:         module2.f90
| |  parent:      3:bc41a66a492a
| |  parent:      2:3d05829cc1c1
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 15:01:45 2012 -0400
| |  summary:     Shule merged his branch with the trunk
| |
| o  changeset:   3:bc41a66a492a
| |  parent:      1:cab73a420c5b
| |  user:        bliu <bliu@pas.rochester.edu>
| |  date:        Thu Jul 26 15:01:03 2012 -0400
| |  summary:     Shule's 2nd modification to Module 1
| |
o |  changeset:   2:3d05829cc1c1
|/   user:        bliu <bliu@pas.rochester.edu>
|    date:        Thu Jul 26 14:54:08 2012 -0400
|    summary:     Eddie added feature 1
|
o  changeset:   1:cab73a420c5b
|  user:        bliu <bliu@pas.rochester.edu>
|  date:        Thu Jul 26 14:00:31 2012 -0400
|  summary:     Shule's 1st modification to module1.f90
|
o  changeset:   0:096f4d37e0fd
   user:        bliu <bliu@pas.rochester.edu>
   date:        Thu Jul 26 13:59:23 2012 -0400
   summary:     Initial commit of TAstroBEAR

• Scheme III
  1. trunk

     @  changeset:   11:320adc42a728
     |  tag:         tip
     |  user:        bliu <bliu@pas.rochester.edu>
     |  date:        Fri Jul 27 10:08:26 2012 -0400
     |  summary:     Eddie fixed 1st bug in module 2
     |
     o  changeset:   10:ba38a00a54d2
     |  user:        bliu <bliu@pas.rochester.edu>
     |  date:        Fri Jul 27 10:07:38 2012 -0400
     |  summary:     Eddie fixed 1st bug in module 1
     |
     o  changeset:   9:b0a88811e50d
     |  user:        bliu <bliu@pas.rochester.edu>
     |  date:        Fri Jul 27 10:04:24 2012 -0400
     |  summary:     Added tag RELEASE_2_0_X for changeset 0a89508c8ca2
     |
     o  changeset:   8:0a89508c8ca2
     |  tag:         RELEASE_2_0_X
     |  user:        bliu <bliu@pas.rochester.edu>
     |  date:        Fri Jul 27 10:03:30 2012 -0400
     |  summary:     Shule created module 2
     |
     o    changeset:   7:1b91941fb44b
     |\   parent:      6:4aac04e39e42
     | |  parent:      5:957430289152
     | |  user:        bliu <bliu@pas.rochester.edu>
     | |  date:        Fri Jul 27 10:01:33 2012 -0400
     | |  summary:     Shule merged his branch with the trunk
     | |
     | o  changeset:   6:4aac04e39e42
     | |  parent:      2:d2bb8f24ef20
     | |  user:        bliu <bliu@pas.rochester.edu>
     | |  date:        Fri Jul 27 09:51:18 2012 -0400
     | |  summary:     Shule made 2nd modification to module 1
     | |
     o |  changeset:   5:957430289152
     | |  user:        bliu <bliu@pas.rochester.edu>
     | |  date:        Fri Jul 27 09:52:24 2012 -0400
     | |  summary:     Eddie fixed the 1st bug in feature 1
     | |
     o |  changeset:   4:2bf0d822ec6f
     | |  user:        bliu <bliu@pas.rochester.edu>
     | |  date:        Fri Jul 27 09:49:03 2012 -0400
     | |  summary:     Eddie created feature 2
     | |
     o |  changeset:   3:307471c2a37e
     |/   user:        bliu <bliu@pas.rochester.edu>
     |    date:        Fri Jul 27 09:44:54 2012 -0400
     |    summary:     Added tag RELEASE_1_0_X for changeset d2bb8f24ef20
     |
     o  changeset:   2:d2bb8f24ef20
     |  tag:         RELEASE_1_0_X
     |  user:        bliu <bliu@pas.rochester.edu>
     |  date:        Fri Jul 27 09:43:34 2012 -0400
     |  summary:     Shule created feature 1
     |
     o  changeset:   1:abd9168ebcbc
     |  user:        bliu <bliu@pas.rochester.edu>
     |  date:        Fri Jul 27 09:40:19 2012 -0400
     |  summary:     Eddie made the 1st modification to module 1
     |
     o  changeset:   0:98888bad8a2a
        user:        bliu <bliu@pas.rochester.edu>
        date:        Fri Jul 27 09:38:33 2012 -0400
        summary:     Initial committment of shceme3
     

2. Release Branch 1.0.x

@  changeset:   6:ecb6fe41824f
|  tag:         tip
|  user:        bliu <bliu@pas.rochester.edu>
|  date:        Fri Jul 27 10:07:38 2012 -0400
|  summary:     Eddie fixed 1st bug in module 1
|
o  changeset:   5:898bd6d22ad9
|  user:        bliu <bliu@pas.rochester.edu>
|  date:        Fri Jul 27 09:51:18 2012 -0400
|  summary:     Shule made 2nd modification to module 1
|
o  changeset:   4:c4c15931c578
|  user:        bliu <bliu@pas.rochester.edu>
|  date:        Fri Jul 27 09:52:24 2012 -0400
|  summary:     Eddie fixed the 1st bug in feature 1
|
o  changeset:   3:307471c2a37e
|  user:        bliu <bliu@pas.rochester.edu>
|  date:        Fri Jul 27 09:44:54 2012 -0400
|  summary:     Added tag RELEASE_1_0_X for changeset d2bb8f24ef20
|
o  changeset:   2:d2bb8f24ef20
|  tag:         RELEASE_1_0_X
|  user:        bliu <bliu@pas.rochester.edu>
|  date:        Fri Jul 27 09:43:34 2012 -0400
|  summary:     Shule created feature 1
|
o  changeset:   1:abd9168ebcbc
|  user:        bliu <bliu@pas.rochester.edu>
|  date:        Fri Jul 27 09:40:19 2012 -0400
|  summary:     Eddie made the 1st modification to module 1
|
o  changeset:   0:98888bad8a2a
   user:        bliu <bliu@pas.rochester.edu>
   date:        Fri Jul 27 09:38:33 2012 -0400
   summary:     Initial committment of shceme3

Latest disk ​Run ​Vertical Profile

I've been porting the resistive solvers to the newest revision. Also have been working on the scaling and set up for the new project: the resistive clump simulations. The set up of our "standard" case is as follows:

ambient density = 1 mg/cc
atomic mass = 12 (carbon)
ambient temperature = 5 ev
density contrast = 100
clump radii = 0.1
tube radii = 0.3
shock speed = 40 km/s (mach 5)
magnetic beta = 4
magnetic reynolds number R_{em}=10
simulation time = 4 crushing times
resolution = 64 zones per clump radii
adiabatic

with two additional runs:
\beta=100$, $R_{em}=10
\beta=4$, $R_{em}=10 with cooling

The magnetic reynolds number of 10 implies that:
t_{mhd}/t_{res}\approx 4.34
i.e. each hydro step requires 4 resistive steps. Therefore the R_{em} = 100 simulations should not require cycling resistive steps, but R_{em} = 1 will be demanding.

I'm currently working on the low resolution version of the runs (with 24 zones per clump radii) to check things. But the production runs should be doable on bluegene. (the previous paper's runs of 192 zones grid takes 4 days with cooling)

Used Jonathan's new refinement objects for my 3D jet simulations. Here's a comparison of how it was refining before to how it refines with the shape object that I defined in the problem module:

	Old Method	New Method
Density
Mesh

3dcoolingjets

I'm also working on setting up a quarter grid simulation which should significantly speed things up.

In a meeting last week, we decided to keep the density contrast (eta) equal to 1 for the runs we want to do. Now, increases in jet and ambient density result in stronger cooling throughout the simulation. Here is a table for proposed runs:

Resolution is based on ~10 cells per cooling length.

I have done 5 new runs, all with BE sphere in a box that is ~ 30 BE radii across. The runs are as follows:

A light case with rho_ambient=0.001rho(Rbe):

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

Here I am seeing the sphere very stable for ~4.5 crossing times, but then it starts pretty fast, and I am not sure what the cause of this would be.. I see that a velocity wave is penetrating inside of the sphere, and it seems like it is tied to the expansion of the sphere at the end. Could this be numerical diffusion at the boundary of the sphere, leaking velocity inward? Since the mass of the ambient cells is so slight, wouldn't expect any momentum to be transferred inward. .

A BE sphere with a 10% density enhancement (Bannerjee and Pudritz setup):

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

This is classic outside in collapse of the BE sphere, markedly different than the matched and intermediate cases.

A BE sphere in an ambient with density that matches the sphere's outer edge:

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

And 3 intermediate densities between rho matched and rho ambient = 0.01 rho(Rbe), in order of densest ambient to lightest:

​http://www.pas.rochester.edu/~erica/Light105July22.gif ​http://www.pas.rochester.edu/~erica/Light70July22.gif ​http://www.pas.rochester.edu/~erica/Light35July22.gif

As a remark on the stable case above, it is definitely stable within the time scales of the other simulations..

• Golden Version AstroBEAR
  1. Modules/Features: ​https://clover.pas.rochester.edu/trac/astrobear/wiki/GoldenVersion
  2. MileStone: ​https://clover.pas.rochester.edu/trac/astrobear/milestone/Build%20Golden%20Version%20of%20AstroBEAR%202.0

• Tickets:
  1. Closed: #226
  2. New: #229, #230, #231
  3. Current Status of Tickets: ​https://clover.pas.rochester.edu/trac/astrobear/query?status=accepted&status=assigned&status=new&status=reopened&group=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=due_date&col=component&col=ttd&col=reporter&order=priority&report=28

• Modification to the code: ​https://clover.pas.rochester.edu/trac/astrobear/log/Scrambler/?action=stop_on_copy&mode=stop_on_copy&rev=b789b34104cbef9b3c0d260dc86175ee7b9042eb&stop_rev=950%3A7afdab9ebdfd&limit=200

• Worked on: Tickets #202, #226, #231

• Improving figures and writing the results section of the disk paper. Latest draft: ​http://www.pas.rochester.edu/~martinhe/adam/paper.pdf
• Pushing the 15AU sim in bluehive and bgene (very sow), close to 2 orbits.
• Pushing the AGN sims.
• Writing job application research proposals.

I looked at the total energies for the non-accreting case and everything looks good.

Total energy seems to flatten out after the first collapse… The 5% error could be due to the softening approximation for the gravitational energy I am using in visit… But the temperature on this run also looks good

Here we see the temperature at the 1st and last frame on a linear scale.

However, with accretion turned on a hot spot develops instantly within the accretion kernel before the disk has had time to collapse or heat… This is certainly a bug that I will look into this weekend.

It looks like the problem module was creating two point gravity objects - and that the additional point gravity object had no softening. This was causing the inside out collapse and the large heating at the center.

Regarding the overheating issue in the disk center.

I did 4 runs with different AMR levels and as you can see in the graph the greater the level the less overheating in the center. I couldn't run a 5 AMR levels simulation due to MPI issues but you can see the trend here.

Although it seems that an increased refinement level solves the overheating issue in the center, I am worried about the spike at the disk/ambient boundary. I am currently looking into that.

In the graph, the X axis is the distance from the center at constant Z, the Y axis is the temperature value.

Presentation: ​http://www.pas.rochester.edu/~shuleli/HedlaPro/0720meeting.ppt

Movies: ​http://www.pas.rochester.edu/~shuleli/HedlaMovie/torxvr.gif

​http://www.pas.rochester.edu/~shuleli/HedlaMovie/torzvr.gif

​http://www.pas.rochester.edu/~shuleli/HedlaMovie/polxvr.gif

​http://www.pas.rochester.edu/~shuleli/HedlaMovie/polzvr.gif

​http://www.pas.rochester.edu/~shuleli/movie0703/mrst.gif

​http://www.pas.rochester.edu/~shuleli/movie0703/mrwk.gif

So Martin showed me how I can set up a particle to have better refinement for my 3D cooling jet sims. The old method was just refining along momentum gradients. Now I am just refining a box around the jet head. Run C, which is the density matched (eta=1) jet is running way faster. It took bluegene 3 days to do 80 frames on 256 procs with the old refining method. With the new refining method, it has taken grass less than 2 hours on 8 procs. Here is a snapshot of the mesh with the new particle refinement:

The next step is to only simulate a quarter of the grid since everything is symmetric. This will make the runs even faster.

- Initial scenario, mach number issue

-Reduced mach number by increasing pressure 10 times
Link​Density evolution

There is a overheating in the 4 central cells at t=0.0025
Link​Overheating

Now looking at the interval t=0 - 0.0025 in 30 frames
Link​Frame0_1
Link​30 frames

Same configuration with a cold ambient
Link​Cold Ambient

- Disabling accretion
Improved temperature behavior
Link​Frame0_1
Link​Side view

- Reducing central mass by a factor of 10
Link​Semi-table
Link​Side view
- Attempt to enable accretion again
Link​Density evolution

Initial results with hydrostatic equilibrium (not really important right now)
Link​Hydrostatic
Accretion should be disabled to make it more stable

First every distance is softened to avoid trouble at origin

Distance from origin: r=>\sqrt(r^2+\epsilon^2)

Distance from rotation axis: s=>\sqrt(r_s^2+\epsilon^2)

Disk radius: r_D=>\sqrt(r_D^2+\epsilon^2)

Then angular velocity is set to be keplerian and balance force along the 's' direction

\Omega=\sqrt{\frac{G M}{s^3}}

Then the density within the disk is set to be constant along the midplane \rho_0 with a decaying exponential to give vertical hydrostatic equilibrium.

\rho=\rho_0 \exp{ \left [ h \left ( \frac{1}{r}-\frac{1}{s} \right ) \right ]}

where the scale height is given by h=\frac{GM}{c_s^2}

At the outer rim of the disk when s > r_D Omega goes to zero and the profile changes slightly to

\rho=\rho_0 \exp{ \left [ h \left ( \frac{1}{r}-\frac{1}{r_D} \right ) \right ]}

which is just the profile for an envelope about a point mass in hydrostatic equilibrium ie \rho \propto \exp(1/r)

Then for each point \rho => \max(\rho, \rho_B) where \rho_B is the disk background density.

Finally additionally smoothing is done in density and pressure between the disk solution and the original cell values at the outer radius using the disk%thickness to define this smoothing distance - although I did just notice a typo if one uses the hydrostatic disk without using an isothermal EOS…

s(iE)=(gamma7*Disk%pressure-q(iE))*f 

should be replaced with

s(iE)=(gamma7*Disk%Pressure/Disk%Density*rho-q(iE))*f

so that if one uses a gamma of 1.0001 the disk is at the same temperature.

So Erica was seeing high velocities and low densities near the boundaries even though the ghost zones were being stepped on with zero velocity and moderate densities every time step. So I setup a simple test problem to verify that this behavior was reasonable. I used a uniform gravity setup but with the top half of the grid being stepped on each time step with the initial values of density, pressure and 0 velocity. I also did a comparison with a reflecting boundary instead to see if it was much different - although there are 'wiggles' that appear in the reflecting case perhaps because of density protections? Here everything has a value of 1… rho, g, P, cs, etc…

Attached is a movie​ showing the behavior of the density and velocity fields for both cases.

I just pushed 951:b789b34104cb in the official repository. This revisions include the bug fixing for blue gene related to ticket #207 and #226.

A update list can be found at
​https://clover.pas.rochester.edu/trac/astrobear/log/Scrambler/?action=stop_on_copy&mode=stop_on_copy&rev=b789b34104cbef9b3c0d260dc86175ee7b9042eb&stop_rev=950%3A7afdab9ebdfd&limit=200

Details of modification to the code can be found at:
​https://clover.pas.rochester.edu/trac/astrobear/changeset?reponame=Scrambler&new=b789b34104cbef9b3c0d260dc86175ee7b9042eb%40&old=7afdab9ebdfdce698c5c6ce0283054919a5ce314%40

Test results can be found at:

​https://clover.pas.rochester.edu/trac/astrobear/wiki/u/bliu#no1

• The material in the disk runs at highly supersonic speeds ~190 Mach, however, it should be stable anyway and shocks should not develop
• The shocks we are seeing are probably due to vertical collapse, a new density distribution is needed
• Hydrostatic equilibrium is being implemented to solve this issue

I have some partial runs of my 3D jet simulations. They are all 256 processor jobs on bluegene with rev 950. Here is that chart of all the runs I want to do:

Run A was not even attempted, run B was taking too long so I have to figure out a better way to refine. Martin showed me how I can use a particle to refine only the jet head. I need to play around with this to make sure I get it right for each simulation. In the meantime, I have submitted restarts for runs C, D, and E to finish them up.

It's kind of tricky to compare the different runs on the same color scale since they are all in slightly different density regimes. Here are snapshots of C, D, and E at the same time:

Run	Chi	Image
C	0.358
D	1.367
E	2.428

Run C ran the longest, so here is a video (the color scale here is different from the color scale above):

rho10.gif​

The majority of my time is spent on studying for the prelim now.

Here are updated movies of my "matched" ambient case:

Note dx = 0.03, and cs=0.4 km/s:

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

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

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

Here is a pic of the mesh:

​http://www.pas.rochester.edu/~erica/MeshZoomed0001.png

I think I am having issues with my restarts. I just ran a bigger sized mesh of this problem on BH and after the restart there I am again seeing a jump in vrad at the boundaries. Also, there appears to be no inflow at the corners of my box. . I am using the winds module to step on the velocity at the boundary. .

Before restart: ​http://www.pas.rochester.edu/~erica/vRadRestart0001.png

After restart: ​http://www.pas.rochester.edu/~erica/vRadRestart0000.png

• Golden Version AstroBEAR:
  1. Current modules running status: ​https://clover.pas.rochester.edu/trac/astrobear/wiki/ProjectStatistics
  2. MileStone: ​https://clover.pas.rochester.edu/trac/astrobear/milestone/Build%20Golden%20Version%20of%20AstroBEAR%202.0

• tickets:
  1. Closed: #204, #208
  2. Current Status: ​https://clover.pas.rochester.edu/trac/astrobear/query?status=accepted&status=assigned&status=new&status=reopened&group=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=due_date&col=component&col=ttd&col=reporter&order=priority&report=28

• Worked on:
  1. Teragrid Proposal: submitted
  2. Ticket #202, #226

Binary

New 10 AU disk mass plot shown along with mass flux out of the grid. The gradients are consistent: the disk mass decreases as the outwards mass flux increases. Thus during the first 3 disk orbits the wind removes a few 10% of the disk mass. It also makes sense that the effect is less significant in the 20 AU case (below); the disk is father away from the primary hence its wind has less ram pressure, by a factor of r-1.
New 20 AU disk mass plot shown along with mass flux out of the grid. The gradients are also consistent.
New 20 AU angular momentum profiles vs disk radius and time. Trying to understand whether these plots are correct and if they tell us something about warping. There are 10 data points per orbit and per coordinate. The momenta are added on spherical shells centered at the secondary. Though our 20 AU disk is far from Keplerian, as shown by the streamline maps, jzKeplerian ~ r½. The 1, 2 and 3 orbit jz profiles (black ones, left panel) are proportional to r~.9.

• 15 AU sim running again, up to .5 orbits and the disk has formed already. Should have the data by next week.

Teragrid proposal and magnetic tower paper submitted.

AGN jet truncation trying to get runs finished. May have some movies here by Tuesday the 17th.

Been working on the resistive stuff. Also updated paper with quantatative analysis:
​http://www.pas.rochester.edu/~shuleli/paperpics_clump1/clumppaper.pdf

• Tickets:
  1. Added due date feature to tickets
  2. Created a new Milestone:
     ​https://clover.pas.rochester.edu/trac/astrobear/milestone/Build%20Golden%20Version%20of%20AstroBEAR%202.0
  3. Current ticket status:
     

​https://clover.pas.rochester.edu/trac/astrobear/query?status=accepted&status=assigned&status=new&status=reopened&group=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=due_date&col=component&col=ttd&col=reporter&order=priority&report=28

• Worked on
  1. Teragrid Proposal:
     
  ​http://www.pas.rochester.edu/~bliu/Proposals/XSEDE_proposal.pdf
  2. Ticket #226, #202

• My jet sims failed to run on bluegene because mpi did not like my astrobear executable. I was having some trouble compiling in bluegene, but changing some lines in my .bashrc seemed to do the trick. The jobs have been resubmitted, so now I wait.

• I merged some of my revisions and updated with the current scrambler repository. This revision which I am now testing will fix a couple of old tickets that I was working on (#171, #198) as well as the NEQ and Z cooling enhancements (#147, #224).

• Disk disrupts at a certain mass/radius ratio
• The mass of the central object is directly proportional to the rate of disruption

Original run (6*10⁶ K ambient, 1000 K disk, 0.6 M_Sun , radius 1.33*10^-3 AU) :
Link​Original Run
Link:​Velocity vectors

Ambient cooler than disk (100 K ambient, 1000 K disk, 0.6 M_Sun) :
Link:​Cool ambient

Central object with little mass (6*10⁶ K ambient, 1000 K disk, 1*10-2 M_Sun) :
Link​Little mass

Central object with no mass (6*10⁶ K ambient, 1000 K disk, 0 M_Sun) :
Link:​No mass

Reference run (Radius = 20au, M_central = 1M_Sun ):
Link​Reference

I have been focusing on the prelim the last week, so no real updates on research stuff. I am attempting to refine my simulation with the use of tracers. It was pretty straightforward to assign a tracer in my simulation, but am still playing with how to control the refinement using the tracer I put inside my clump.

• Found bug in reflecting self-gravity #228
• working on scaling - #202
• implementing new refinement criteria/implementation #225

All runs are finished and looking good. New Figures for the paper are here (too many):
​link
fig03: strong toroidal(beta=0.25), aligned with the shock.
fig04: strong toroidal(beta=0.25), perpendicular with the shock.
fig05: strong poloidal(beta=0.25), aligned with the shock.
fig06: strong poloidal(beta=0.25), perpendicular with the shock.
fig07: weak toroidal(beta=0.25), aligned with the shock.
fig08: weak toroidal(beta=0.25), perpendicular with the shock.

fig12: kinetic energy transfer and total magnetic energy for the strong contained field cases.
fig13: kinetic energy transfer and total magnetic energy for the weak contained field cases.
fig14: mixing ratio at tcc and 3tcc for the strong contained field cases.
fig15: mixing ratio at tcc and 3tcc for the weak contained field cases.

Volume rendered movie for one special case: strong poloidal perpendicular to demonstrate the clump morphology evolution:
​movie
Mixing ratio has very different behavior when the contained field pressure is changed: in the strong contained field cases, the initial mixing ratio look almost identical but then develops differences as the simulations went on. But in the weak contained field cases, there is a sharp difference between the toroidal and poloidal configurations.
Movie of mixing ratio for the strong contained case:
​movie
Movie of mixing ratio for the weak contained case:
​movie

Initial parameters are all set:

• Central star mass: 0.6 M_sun
• Disrupted companion mass: 10 M_Jupiter

• Current issue with ratio M_disk/M_central

Density plot: Temperature plot:

• Tickets:
  1. New Tickets: #228
  2. Closed Tickets: #223
  3. Current Open Tickets: ​https://clover.pas.rochester.edu/trac/astrobear/query?status=accepted&status=assigned&status=new&status=reopened&group=priority&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=component&col=ttd&col=reporter&order=priority&report=28

• Worked on
  1. Teragrid Proposal: ​http://www.pas.rochester.edu/~bliu/Proposals/XSEDE_proposal.pdf
  2. Kraken Scaling Tests: #202
  3. #226: Reserved 256 cores on blue gene for Thu and Fri

• Current 103rd on Top 500!!!
  ​http://www.pas.rochester.edu/~bliu/BlueGeneQ-delivery/P1010020.JPG

This past week I have:

*Read the Hannebelle paper (very good/pertinent to what I am doing now).

*Added Poisson BC parameters under the tutorials>data files explained>global.data

And worked on the following sims:

*Reflecting quandrant of sphere:

I learned more about the role of BCs in fluid simulations. That is, how they control the fluid variables across boundaries. For instance, when slicing through a symmetric object, the boundaries on the faces of the slice should be reflecting so the flow at that boundary is the same, as it would be by symmetry. I also learned more about why using extrapolating BCs at a boundary for subsonic flow may lead to issues — it has to do with the ghost region copying data from adjacent domain cells. If the fluid variables copied are pointing in the 'wrong' direction, which may happen from random thermal motions in a subsonic flow, they will be pasted inside the neighboring domain cell and subsequently the flow will be flowing in the wrong direction inside this boundary. I learned that the winds module when used will set any inflow to be 0, but will allow outflow. With these in mind, I set the domain BC's to be reflecting on the 3 faces of the sliced sphere, and used the winds module on the other sides (periodic was NOT an option, as you need a pair of boundaries for periodic to work!). As far as the elliptic boundaries go, I am using reflecting as well on the same 3 sides, and multipole everywhere else. I am unsure of how to proceed from here, given that sim. is currently stuck (see ticket - ​https://clover.pas.rochester.edu/trac/astrobear/ticket/228)

*Larger box size, higher refinement inside the BE sphere:

I learned why refinement was not being triggered in my matched ambient simulation (see ticket 223). After making an adjustment to my problem module, am now running this set up on the larger domain (30.8³) with 6 levels of refinement. This is refining the clump to about 33 cells per radius. I am running the sim out to t=0.2, which is about 2x longer than the time it took for Pthermal>Pcrit, and with 200 frames. This will give us a temporal resolution ~ 10 x greater than before so we can see more clearly the cause of the anomalous "bounce" that concerned us before.

I am also rerunning the Light ambient case at the same resolution, 30³ + 6 levels.

Both of these sims are using the winds module at the domain boundary, and multipole for the elliptic.

Concerning refinement of the matched case. If we are interesting in refining the clump down to 10% its original size with 30 cells p/ radius, 7 levels of refinement would be sufficient. However, this seems a HIGHLY inefficient way to refine as I am currently refining now — with a geometric condition. A much better way would be to use Jean's length again, but to figure out how to restrict the Jeans refinement to be only within the sphere (not the Jeans unstable ambient medium). Will talk to Jonathan about this.

The matched ambient case is more than half way done now (external pressure on the sphere's edge should exceed threshold by now), and the light is ~ 1/10 the way. Hope to post figures/movies with the results by the meeting tomorrow — at least what I'll have so far by then.