Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.mso.anu.edu.au/coala/sharon.html
Дата изменения: Unknown Дата индексирования: Mon Oct 1 21:22:56 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п п п п |
Student
Brian Schmidt
While GRBs provide a powerful tool to study galaxy formation at high redshifts, they also represent a unique setting to observe extreme physical processes. Extensive research on Long GRBs has found them to typically be associated with the collapse of a massive star. However, the exact features of this process are not yet understood, and is especially poorly constrained in the very bright GRBs used to study the high-redshift universe. This proposal seeks to investigate the properties of the GRB-SN and therefore enhance our understanding of the GRB central engine, GRB progenitors, and the associated physical properties.
Long-duration GRBs are associated with broad-line Ibc Supernovae. Studies reveal a possible linkage between the metallicity in the environment of the Supernova and whether it will produce a GRB (Sollerman et al., 2005; Modjaz et al., 2008, 2006). However, conclusive results are still limited due to the small sample of 4 certain GRB-SN connections, only one of which has been properly modelled (2003dh). Sollerman et al observed 3 galaxies which were identified to host a SN with an associated GRB. Their results favour low metallicity, sub-luminous galaxies with L < L* and Z < Z* in their star forming phase, which agrees with other studies of higher redshift GRBs (Le Floc'h et al., 2003). A study of SN 1998bw confirms the high mass Collapsar model (Woosley, Eastman and Schmidt 1998, MacFayden and Woosley 1999) with an estimated progenitor mass of ~ 30M_solar, but this object's Gamma Ray Burst properties were orders of magnitude less energetic than the typical GRBs we study at large redshifts. In 2003, SN2003dh/GRB 030329 became the first bright GRB to have its SN studied in detail. It remains unique in this respect to date. Since GRB030329, a series of GRB-SN have been studied,( GRB031203, GRB060218, GRB080110, and GRB100316 - see table) , but all of these are intrinsically dim GRBs, unlike SN2003dh.
A significant part of Rapoport's PhD thesis will be dedicated to better understand the Supernovae that become GRBs, and to investigate the connections between GRB central engines and the progenitor stars that explode. Therefore, we propose to model the exploding star's mass, total explosion energy, 56Ni production (which probes the central engine of the GRB/SN), and potentially, a-sphericity using Sim's radiative transfer Monte-Carlo code. These measurements should help better define the progenitor systems that lead to bright GRBs, illuminate the range of physics that lead to bright GRBs, and allow us to better understand and predict the biases that are associated with using GRBs as tracers of star formation.
The computations (Monte Carlo radiative transfer code) would all be performed in a batch mode with parallel processors. The code has already been extensively tested and used on the machines at MPA and scales very well up to several thousand processors - so it will perform very well on a machine with a moderate numbers of processors like Coala. The code has a hybrid MPI-OPENMP parallelisation so that it can run on systems with either (or both) in operation. Coala does not have enough processors for me to undertake full multi-dimensional simulations - for these I will apply for time via the ANU partner share on the big machine. However, Coala will be ideal for doing code development tests (I plan to add several new capabilities to the code in the near future - polarization and late-phase nebular spectra) and should also be adequate for running 1D models (which will form the initial phase of work on the modelling of SN Ib/c). I would expect that a serious test calculation might use around 32 or 64 processors for anywhere from a few hours up to one day. A full production-level 1D calculation (with all physics switched on) would use up to 64 processors for a few days. [The code can be restarted from any state so, although production level simualtions will require fairly long integrated run times, they do not require that resources be allocated continuously for a very long period.]