• Used remaining hours on Kraken to run a 3 Jupiter Mass sim for 4 orbits (no more time is available !)
• Still working on sim plots.
• Introduced AstroBEAR to Andrew, we are going to meet up again on Wednesday.

I've worked on a few plots yesterday (​plots), radial measurements of density and temperatures, I need to discuss them in detail with Jason.

I am meeting with Andrew Lipnicky on Wednesday and introducing the code to him.
Andrew will probably need access to the repository to download new AstroBEAR revisions in the future.

Came back from the AAS meeting!

Resuming analysis of Kraken runs today.

Should make a blog post on new plots towards the end of the week.

Made a plot of accretion rates.

Each model has 2 lines: Total accretion (rate at which the central particle accretes), Tracer accretion (rate at which the central particle accretes disk material).
Two things worth noticing: 1) The central particle is accreting a big deal of material from the ambient and much less from the disk. 2) The 20 Jupiter Mass behaves differently compared to the other two models.

• We started analyzing the runs and making plots.
  

The accretion disks start with the same pressure and different densities, as suggested in paper meeting we had back then, as a consequence they also differ in temperatures.

Let's remember the initial conditions briefly:

Although the disks start with different initial conditions, they appear to settle at the similar temperatures. We decided to measure the disk mass using temperature to determine what material belongs to the disk, as of right now this seems to be the best option, suggestions are welcome.

The threshold we decided to use is 2d6K. To visualize this value the plot below can come in handy:

This being said, below are two plots of our 4 runs, the first one is relative mass, the second is absolute mass. Part of the 5 Jupiter Mass line is dotted (predicted mass) since we decided to extend that run a bit to get it to 10 orbits.

• There is a vortex-like feature going on with the 20 Jupiter Mass. It does not compromise the general picture, however, it is something to think about. What could be causing it ? Movie ​here

• We need to check accretion rates since they seem a little bit too high. I will check them in detail later on this week.

Runs on Kraken are complete. We are only running the 5 Jupiter mass for a little bit longer to see it disrupt.
I begun analyzing evolution of disk mass over time and sent a few plots to Jason.
We are currently deciding what criteria to use to determine what material is part of the disk.

• Runs

Should be done tomorrow.

• Movies:
  

1 Jupiter Mass ~3 orbits (complete) ​movie
5 Jupiter Mass 5 orbits (complete) ​movie
10 Jupiter Mass 10 orbits (almost complete) ​movie
20 Jupiter Mass 10 orbits (almost complete)

• Bug

Appears to be solved with threading disabled.
Created ticked to document the issue ​268

Runs:

• 1 Jupiter mass almost complete. ​movie here
  
• 10 Jupiter mass running.​movie here
  

• 20 and 5 Jupiter mass stopped because of a bug

​bug1
​bug2

what could be the cause ?

• affects multiple runs
• can happen before or after a restart
• golden version
• happens in different parts of the box
• doesn't seem to be a 'stepping on the boundary' kind of bug since it should be a little more symmetric.

Any ideas ?

We are running our production sims on Kraken and Ranger.
They will likely to be complete after the break. In the meantime, I worked on getting visit to run in parallel on Kraken and we now have some partial frames from the first run, that is, 1 Jupiter mass accretion disk.

Movie (0 → 1.5 orbits): ​here

The patterns we noticed in the previous sims are now more visible. Below are stills of frames 4 to 7, (for color legend look at the movie linked above).

Density profile (horizontal slice).

This run definitely features heavy mixing between the cold disk material and the hot ambient.

Temperature profile (vertical slice).

Last week of work for me (Ivan).

A little summary of what we have done:

• We begun with a disk embedded in a uniform and hot ambient
• Material infall from the ambient would invalidate our initial conditions
• Developed a HSE solution to keep the ambient stable
• Put the disk back in the stable ambient
• Got acceptable results
• Now waiting for production runs to finish

Agenda for the week:

• Add modules used for runs to AstroBEAR repo (for future reference or work)
• Get production runs done (it is just a matter of waiting).
  

BE_HSE:
Should be picked up and developed by someone, it looks promising.



Parallel HDF5:
see blog post ​here

Why ?
Serial HDF5 can be slow:

• when many processes try to write/read to same file
• when handling large files
• when a large amount of IO is done (postprocessing…)

How AstroBEAR handles IO:
Master queries all processes asking for data, data is then written to chombo file.

Original image from ​http://www.astro.sunysb.edu/mzingale/io_tutorial/

Simplified version of astrobear IO routine:

offset = 0
for every active process
   fectch data
   write data to chombo beginning at offset
   update offset

How this would be done in parallel:
Every process would write at a different offset.

Original image from ​http://www.astro.sunysb.edu/mzingale/io_tutorial/

Requirements of parallel hdf5 usage:

• MPI-IO (should be on all machines)
• Parallel filesystem (not on all machines)

PHDF5 should be considered as an addition, not a replacement for serial HDF5.

Parallel file accessing aspects:
All processes that have access to a file must do basic operations collectively:

• Open/close/create file
• Open/close/extend datasets

Other operations can be done either collectively or independently:

• File read
• File writes

The easy part:

• The two libraries are incredibly similar.
• We can adapt our serial routines to use parallel, not implement parallel IO from scratch.

The challenging part:

• Every process must know where to write.
  
• An algorithm is needed.
  
• Concept explained in image below

Production runs:

• Currently running on BlueStreak
• Had 4 models initially (20 M_J,10 M_J,5 M_J,1 M_J,)
• 1 Jupiter Mass Disk sim was stopped at ~2 orbits (it was almost completely disrupted).
  
• We now have a nice intermediate case (5 M_j)
  

Initial conditions:

~ 1 Orbit

~ 2 Orbits

… While we wait for the production runs to advance.

BE sphere:
Mini movie of a .25 M_J BE sphere orbiting around hydrostatic star core:
The sphere is within the shredding radius.

Golden version:
Tagging question. Copyright year ?
X-2012

• Finished 6 AMR runs. Updated mass loss comparison
  

• New disk runs with thin disk, vertical smoothing and accretion enabled.
  
  

I didn't notice that switching to 5 AMR levels still leaves one single cell to vertical smoothing, which is not ideal.
The movie reveals something interesting though ​Thin disk movie compared to ​Thick disk movie

• Initial images of BE sphere in Hydrostatic ambient
  
  

We are preparing for production runs:

• Tests runs can be found ​here
• Probably need to rerun some sims using tracer fields as suggested by Jason and Adam Frank. Currently, a visit expression based on position, x-z velocity and density is used to measure the mass of the disk.
• Disk tracer test ​here
• We are currently looking at how many AMR levels we need to have accurate results.
• Waiting for the first 32x32x32x6 sim. Was submitted on fri morning and expected to run sat night but keeps getting delayed.

• Migrated HSE to 3D (​post here).
• Inserted accretion disk back in the model (​post here)
• I ran the disk simulation up to t=1, the movies in the linked blog post go up to t=0.7. I haven't noticed any significant events.
• I am a little bit concerned with the contrast in temperature at t=0 between disk and ambient ​pic
• Updated/created a few wiki pages
• User's Manual ? Good idea or not ?

I've put the disk back in the ambient, here are some very early results.
There isn't any overly exciting event with this configuration, maybe I should run it for a little bit more time.
Anyway, I've got two movies that we can discuss in the next meeting
​density movie, ​temperature movie.
There is some evolution going on with the disk, however, the ambient does not undergo big changes, you can see this better when you compare t=0 to t_final=0.7=~4h

This morning I ran a simulation of the HydroStatic Star module in 3D. The simulation was successful and stable.
A remarkable fact is the change in the pressure profile that leads to a more natural temperature profile. Here are the two models compared, they have an identical density profile but differ in pressure profiles and therefore temperature profiles. This is most likely due to the switch from plummersoftening2D to its 3D version.
Edit (Jonathan explained the reason for the change): in 2D the point gravity object is actually a line charge, so the force falls with 1/r rate. in 3D it is 1/r²

I ran the 3D model with 4 AMR levels, and this led to less mass loss and increased stability overall. Computational time was not too long (~2 hours on 32 cores). ​movie

As I did with our 2D simulation, I compared the values of this new 3D model with the refence model, I was able to load all the values in the same plot this time for a better understanding. Legend:

• continuos lines: reference model
• dots: our model
• blue/purple: pressure
• red/orange: temperature
• gray/green: density

Overall, this looks like a good result to me. The next step is to put our accretion disk back in the picture.

So we had some new developments since last week with the Hydrostatic Equilibrium module. I thought I would give an update on were we are at now.
We now have a model that is stable enough to be suitable for a simulation.
Below is a plot that shows pressure, temperature and density profiles in logscales, also, you can get an impression on what the velocity magnitude and mach numbers are.

Here of density and pressure evolution of the model ​movie1
Jonathan fixed the density infall from the boundaries and the model is stable up to t=1, with a timeScale = 17403 second =~ 5 hours. There is still some, although not excessive, expansion of the central part.

Things get a little bit ugly when we see the plots for temperature and mach numbers. ​movie2
There is still an inverse profile for the temperature, apparently trying to change it represents a cause of instability, but we can push it a little bit. The Mach number plot seems to be affected by some AMR related issue, Jonathan hinted the possibility of such an issue today at the meeting. I will look into that.

Last but now least, lets see how our profile compares to the model of an AGB star (the refence model can be found ​here ). The plots below represent our model (first image) and the reference model (second image).

The two models are not perfectly identical for the central part of the star (where r ≤ 4). This is related due to the smoothing that we had to apply to density and gravity potential. However, for our specific problem, the central part of the star will be covered by an accretion disk. Below are the same plots as above but translated by 4 units so that you can see how the two profiles compare at a r ≥ 4.

• What is left to do is to tweak the temperature profile a bit, bring the problem to 3D, and place our accretion disk in.

HSE:
We are obtaining the new HSE code/module from the repository.
Jonathan sent us a ​movie of the new module.

AstroBEAR code improvements:
Ticket ​250: module control is now able to keep track of objects creation order for gridinit, beforestep and seterrflag calls.
Different routines such as <object>RemoveFromList, <object>GridInit, <module>Init, were removed or ported to the new object module.
Work is complete, code is being tested and merged.

The new code behaves exactly like the old one (for now) for testing purposes.
This is an example of the GridInit subroutine of module control:

      CALL ObjectsGridInit(Info,AMBIENTOBJ)
      CALL ObjectsGridInit(Info, COLLIDINGFLOWOBJ)
      CALL ObjectsGridInit(Info,CLUMPOBJ)
      CALL ObjectsGridInit(Info, DISKOBJ)
      CALL ObjectsGridInit(Info, WINDOBJ)
      CALL ObjectsGridInit(Info, OUTFLOWOBJ)
      CALL ObjectsGridInit(Info, UNIFORMREGIONOBJ)
      CALL ObjectsGridInit(Info, SPLITREGIONOBJ)

and ObjectsGridInit(Info,type) in objects.f90:

DO WHILE(ASSOCIATED(Object))
   IF (Object%type == TYPE) THEN
      CALL ObjectGridInit(Info, Object)
   ENDIF
   Object => Object%next
END DO

The object type hierarchy is still used although a creation time priority is followed among same-type objects. Before proceeding to a creation time only ordering, we have to make sure each problem module instantiates its objects in a correct order, as Jonathan correctly mentioned.

Licensing:
Ticket ​256 - tagging script deployed. It is simply a matter of running it inside the repository.
Below is the copyright notice that will appear in each file (Disk.f90 example):

    Copyright 200x-2012 Department of Physics and Astronomy, University of Rochester.

    Disk.f90 is part of AstroBEAR.

    AstroBEAR is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    AstroBEAR is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with AstroBEAR.  If not, see <http://www.gnu.org/licenses/>.

Full license version that has to appear once is the code can be found at ​http://www.gnu.org/licenses/gpl.txt.

AstroBEAR related updates:

• created a script for source code tagging, waiting for group decision regarding author tags.
• ticket 250 (unifying calls among object modules) in the workings.

Research related updates:

• minimal velocities at beginning of evolution
• instability develops and is amplified with time ​turbulence

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.

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

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

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 )

HSE:

• Jason will be reviewing calculations done so far

AstroBEAR enhancements:

• Working on ticket ​#248

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

So I've finished writing the ​Disk module tutorial that I mentioned yesterday at the meeting.
You are invited to give a glance to the page and let me know if you think anything should be added, removed or changed to make it better. You can also directly edit the page if you need to make minor changes.
Any type of feedback wanted !

We are heading towards an hydrostatic equilibrium solution.
There are 2 possible approaches, we are currently evaluating the best path to follow.

* Scenario 1 (Manual density profile):

User defined variables: density profile ⇒ rho₀*(r/r₀)-2
Pressure would be calculated accordingly by the hydrostatic equation.
Temperature can be changed by adjusting the density profile.

Pros:

• Is the classic implementation of the hydrostatic equilibrium
  
• Density profile is consistent with AGB stars models

Cons:

• P(r) involves integral calculation
  
• Scarce usage of astrobear functions, introduces a window for errors
  
• Temperature profile could not be what we want for our type of simulations
  
  

* Scenario 2 (Isothermal profile, suggested by Jonathan):

User defined variables: constant ratio (pressure/rho)
Pressure and density would be calculated accordingly

Pros:

• Usage of astrobear common functions, less possbility of errors
  
• Does not involve manual calculation of integrals
  
• Gives us the temperature profile that we need
  

Cons:

• Density profile could not be disk friendly

So far we have done different runs:

Batch 1 (4 runs):
Constant parameters:
Central mass = .4 M_Sun
Disk mass = 10 M__Jupiter
Disk radius = 2e10 cm
Disk height = 2e9 cm
Disk temperature = 4000 K
Ambient density = 0.001 g/cc
Variable parameters:
Ambient temperature = 1e6K | 5e6K | 1e7K | 5e7K
Preview:​Batch1_preview

Batch 2 (4 runs):
Constant parameters:
Central mass = .4 M_Sun
Disk radius = 2e10 cm
Disk height = 2e9 cm
Disk temperature = 4000 K
Ambient density = 0.001 g/cc
Ambient temperature = 5e6 K
Variable parameters :
Disk Mass = .1 | .5 | 1 | 10 M_Jupiter
Preview: ​Batch2_preview

In all the cases the ambient is attracted towards the central object, this generates velocity and temperature, and a heat bubble embeds the disk. A new hydrostatic equilibrium module (the current one implements constant pressure, which is not appropriate in our case) is needed to prevent the ambient from generating heat.

Latest disk ​Run ​Vertical Profile

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.

- 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

• 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

• 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

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: