Commits August 2011

commits@lists.einsteintoolkit.org

9 participants
99 discussions

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 103)
by cott＠tapir.caltech.edu 11 Aug '11

11 Aug '11

User: cott Date: 2011/08/11 04:31 AM Modified: / ET.tex /local_bibtex/ ott_references.bib Log: * more EOS text File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +6 -0 =================================================================== --- ET.tex 2011-08-10 18:53:50 UTC (rev 102) +++ ET.tex 2011-08-11 09:31:45 UTC (rev 103) @@ -1445,7 +1445,13 @@ \cite{dimmelmeier:07}), the hybrid EOS leads to qualitatively correct collapse and bounce dynamics in stellar collapse. +\codename{EOS\_Omni} also integrates the \codename{nuc\_eos} driver +routine, which was first developed for the \codename{GR1D} code by +O'Connor \& Ott \cite{oconnor:10}, for tabulated microphysical +finite-temperature EOS that assume nuclear statistical equilibrium +(NSE). + {\color{red} continue here} Directory: /local_bibtex/ ========================= File [modified]: ott_references.bib Delta lines: +11 -0 =================================================================== --- local_bibtex/ott_references.bib 2011-08-10 18:53:50 UTC (rev 102) +++ local_bibtex/ott_references.bib 2011-08-11 09:31:45 UTC (rev 103) @@ -199,3 +199,14 @@ volume = 98, pages = {251101}, } + +@ARTICLE{oconnor:10, + author = {{O'Connor}, E. and {Ott}, C.~D.}, + title = "{A New Open-Source Code for Spherically-Symmetric Stellar Collapse to Neutron Stars and Black Holes}", + journal = {Class. Quantum Grav.}, + volume = 27, + pages = 114103, + year = 2010, + adsurl = {http://adsabs.harvard.edu/abs/2009arXiv0912.2393O}, + fnote = {Supported by NSF AST-0855535}, +}

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 102)
by cott＠tapir.caltech.edu 10 Aug '11

10 Aug '11

User: cott Date: 2011/08/10 01:53 PM Modified: / ET.tex /local_bibtex/ ott_references.bib Log: * some EOS text, more to come. File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +99 -6 =================================================================== --- ET.tex 2011-08-08 01:40:52 UTC (rev 101) +++ ET.tex 2011-08-10 18:53:50 UTC (rev 102) @@ -1265,15 +1265,44 @@ \subsection{Hydrodynamics Evolution}\pages{Christian and Josh} \label{sec:GRHydro} -Hydrodynamic evolution in the Einstein Toolkit is designed so that it interacts with the metric curvature evolution through a small set of variables, allowing for maximum modularity in implementing, editing, or replacing either evolution scheme. +Hydrodynamic evolution in the Einstein Toolkit is designed so that it +interacts with the metric curvature evolution through a small set of +variables, allowing for maximum modularity in implementing, editing, +or replacing either evolution scheme. -The primary hydrodynamics evolution routine in the Einstein Toolkit is \codename{GRHydro}, a public version derived from the \codename{Whisky} code designed primarily by researchers at AEI and their collaborators \cite{Baiotti:2004wn,Hawke:2005zw,Baiotti:2010zf,Whisky:web}. It includes a high resolution shock capturing (HRSC) scheme to evolve hydrodynamic quantities, with several different reconstruction methods and Riemann solvers, as we discuss below. In such a scheme, we define a set of ``conserved'' hydrodynamic variables, defined in terms of the ``primitive'' physical variables such as mass and internal energy density, pressure, and velocity. Wherever derivatives of hydrodynamic terms appear in the evolution equations for the conserved variables, they are restricted to appear only inside divergence terms, which are referred to as fluxes. By calculating fluxes at cell faces, we may obtain a consistent description of the intercell values using reconstruction techniques that account for the fact that hydrodynamic variables are not smooth and may not be finite differences accurately. All other source terms in the evolution equations may contain only the hydrodynamic variables themselves as well as the metric variables and derivatives of the latter, since they must formally be smooth and thus differentiable using finite differencing techniques. Summarizing these methods briefly, the following stages occur every timestep: +The primary hydrodynamics evolution routine in the Einstein Toolkit is +\codename{GRHydro}, an updated version of the public \codename{Whisky} +code \cite{Baiotti:2004wn,Hawke:2005zw,Baiotti:2010zf,Whisky:web}. It +includes a high resolution shock capturing (HRSC) scheme to evolve +hydrodynamic quantities, with several different reconstruction methods +and Riemann solvers, as we discuss below. In such a scheme, we define +a set of ``conserved'' hydrodynamic variables, defined in terms of the +``primitive'' physical variables such as mass and internal energy +density, pressure, and velocity. Wherever derivatives of hydrodynamic +terms appear in the evolution equations for the conserved variables, +they are restricted to appear only inside divergence terms, which are +referred to as fluxes. By calculating fluxes at cell faces, we may +obtain a consistent description of the intercell values using +reconstruction techniques that account for the fact that hydrodynamic +variables are not smooth and may not be finite differences accurately. +All other source terms in the evolution equations may contain only the +hydrodynamic variables themselves as well as the metric variables and +derivatives of the latter, since they must formally be smooth and thus +differentiable using finite differencing techniques. Summarizing +these methods briefly, the following stages occur every timestep: \begin{itemize} -\item The primitive variables are ``reconstructed'' at cell faces using shock-capturing techniques, with total variation diminishing (TVD), piecewise parabolic (PPM), and essentially non-oscillatory (ENO) methods currently implemented. -\item A Riemann problem is solved at each cell face using an approximate solver. Currently implemented versions include HLL (Harten-Lax-van Leer), Roe, and Marquina solvers. -\item The conserved variables are advanced a timestep, and used to recalculate the new values of the primitive variables. +\item The primitive variables are ``reconstructed'' at cell faces + using shock-capturing techniques, with total variation diminishing + (TVD), piecewise parabolic (PPM), and essentially non-oscillatory + (ENO) methods currently implemented. +\item A Riemann problem is solved at each cell face using an + approximate solver. Currently implemented versions include HLL + (Harten-Lax-van Leer), Roe, and Marquina solvers. +\item The conserved variables are advanced a timestep, and used to + recalculate the new values of the primitive variables. \end{itemize} -We discuss the GRHD formalism, the stages within a timestep, and the other aspects of the code below. +We discuss the GRHD formalism, the stages within a timestep, and the +other aspects of the code below. \subsubsection{Ideal general relativistic hydrodynamics (GRHD)} The equations of ideal GR hydrodynamics evolved by \codename{GRHydro} are @@ -1356,6 +1385,70 @@ \subsection{Equations of State}\pages{1 Christian} \label{sec:eoss} +An equation of state connecting the primitive state variables is +needed to close the system of GR hydrodynamics equations. The module +\codename{EOS\_Omni} provides a unified general equation of state +(EOS) interface and backend for simple analytic and complex +microphysical EOS. + +The polytropic EOS, +\begin{equation} +P = K\rho^\Gamma\,\,, +\end{equation} +where $K$ is the polytropic constant and $\Gamma$ is the adiabatic +index, is appropriate for adiabatic (= isentropic) evolution without +shocks. When using the polytropic EOS, one does not need to evolve the +total fluid energy equation, since the specific internal energy +$\epsilon$ is fixed to +\begin{equation} +\epsilon = \frac{K\rho^\Gamma}{(\Gamma - 1)\rho}\,. +\end{equation} +Note that the adiabatic index $\Gamma = d\ln{P}/ +d\ln{\rho}$ is related to the frequently used polytropic index $n$ via +$n = 1 / (\Gamma - 1)$. + +The gamma-law EOS\footnote{For historic reasons, this EOS is referred to +as the ``ideal fluid'' EOS in \codename{GRHydro}.}, +\begin{equation} +P = (\Gamma - 1) \rho \epsilon\,\,, +\end{equation} +allows for non-adiabatic flow, but still assumes fixed microphysics, which +is encapsulated in the constant adiabatic index $\Gamma$. This EOS has been +used extensively in simulations of NSNS and NSBH mergers. + +The hybrid EOS, first introduced by \cite{janka:93}, is a 2-piece +piecewise polytropic with a thermal component designed for the +application in simple models of stellar collapse. At densities below +nuclear, a polytropic EOS with $\Gamma = \Gamma_1 \approx 4/3$ is +used. To mimick the stiffening of the nuclear EOS at nuclear density, +the low-density polytrope is fitted to a second polytrope with +$\Gamma = \Gamma_2 \gtrsim 2$. To allow for thermal contributions to the +pressure due to shock heating, a gamma-law with $\Gamma = \Gamma_\mathrm{th}$ +is used. The full EOS then reads +\begin{eqnarray} + P & = & \frac{\Gamma - \Gamma_{\rm th}}{\Gamma - 1} + K \rho_{\rm nuc}^{\Gamma_1 - \Gamma} + \rho^{\Gamma} - \frac{(\Gamma_{\rm th} - 1) (\Gamma - \Gamma_1)} + {(\Gamma_1 - 1) (\Gamma_2 - 1)} + K \rho_{\rm nuc}^{\Gamma_1 - 1} \rho \nonumber \\ + & & + (\Gamma_{\rm th} - 1) \rho \epsilon\,. + \label{eq:hybrid_eos} +\end{eqnarray}% +mIn this, $\epsilon$ denotes the total specific internal energy which +consists of a polytropic and a thermal contribution. In iron core +collapse, the pressure below nuclear density is dominated by the +pressure of relativistically degenerate electrons. For this, one sets +$K = 4.897 \times 10^{14}$ [cgs] in the above. The termal index +$\Gamma_{\rm th}$ is usually set to $1.5$, corresponding to a mixture +of relativistic ($\Gamma=4/3$) and non-relativistic ($\Gamma=5/3$) +gas. Provided appropriate choices of EOS parameters (e.g., +\cite{dimmelmeier:07}), the hybrid EOS leads to qualitatively correct +collapse and bounce dynamics in stellar collapse. + + +{\color{red} continue here} + + \subsection{Analysis\pagesdone{Tanja}} \label{sec:analysis} It is often beneficial and sometimes necessary to evaluate analysis quantities Directory: /local_bibtex/ ========================= File [modified]: ott_references.bib Delta lines: +22 -0 =================================================================== --- local_bibtex/ott_references.bib 2011-08-08 01:40:52 UTC (rev 101) +++ local_bibtex/ott_references.bib 2011-08-10 18:53:50 UTC (rev 102) @@ -177,3 +177,25 @@ number = 6, pages = {064008}, } + +@Article{ janka:93, + author = {{Janka}, H.-T. and {Zwerger}, T. and {M\"onchmeyer}, R.}, + title = "{Does artificial viscosity destroy prompt type-II + supernova explosions?}", + journal = {Astron. Astrophys.}, + year = 1993, + month = feb, + volume = 268, + pages = {360} +} + +@ARTICLE{dimmelmeier:07, + author = {{Dimmelmeier}, H. and {Ott}, C.~D. and {Janka}, H.-T. and {Marek}, A. and + {M{\"u}ller}, E.}, + title = "{Generic Gravitational-Wave Signals from the Collapse of Rotating Stellar Cores}", + journal = {Phys. Rev. Lett}, + year = 2007, + month = jun, + volume = 98, + pages = {251101}, +}

1 0

[svn:einsteintoolkit] incoming/PITTNullCode/ (Rev. 55)
by yosef＠astro.rit.edu 09 Aug '11

09 Aug '11

User: zlochower Date: 2011/08/09 05:08 PM Modified: /PITTNullCode/NullExact/src/ NullExact_MoLRegister.c /PITTNullCode/NullPsiInt/src/ NullPsiInt_MoLRegister.c, NullPsiInt_dotNewsPsi.F90 /PITTNullCode/SphericalHarmonicRecon/src/util/ ascii_output.c Log: Fixes for compiler warnings. File Changes: Directory: /PITTNullCode/NullExact/src/ ======================================= File [modified]: NullExact_MoLRegister.c Delta lines: +1 -1 =================================================================== --- PITTNullCode/NullExact/src/NullExact_MoLRegister.c 2011-08-09 17:55:57 UTC (rev 54) +++ PITTNullCode/NullExact/src/NullExact_MoLRegister.c 2011-08-09 22:08:32 UTC (rev 55) @@ -39,5 +39,5 @@ if (ierr) CCTK_WARN(0,"Problems registering with MoL"); - return ierr; + /* return ierr; */ } Directory: /PITTNullCode/NullPsiInt/src/ ======================================== File [modified]: NullPsiInt_MoLRegister.c Delta lines: +1 -1 =================================================================== --- PITTNullCode/NullPsiInt/src/NullPsiInt_MoLRegister.c 2011-08-09 17:55:57 UTC (rev 54) +++ PITTNullCode/NullPsiInt/src/NullPsiInt_MoLRegister.c 2011-08-09 22:08:32 UTC (rev 55) @@ -51,5 +51,5 @@ if (ierr) CCTK_WARN(0,"Problems registering with MoL"); - return ierr; + /* return ierr; */ } File [modified]: NullPsiInt_dotNewsPsi.F90 Delta lines: +1 -1 =================================================================== --- PITTNullCode/NullPsiInt/src/NullPsiInt_dotNewsPsi.F90 2011-08-09 17:55:57 UTC (rev 54) +++ PITTNullCode/NullPsiInt/src/NullPsiInt_dotNewsPsi.F90 2011-08-09 22:08:32 UTC (rev 55) @@ -6,7 +6,7 @@ subroutine NullPsiInt_dotNewsPsi(CCTK_ARGUMENTS) use cctk - use NullInterp + !use NullInterp use NullGrid_Vars implicit none Directory: /PITTNullCode/SphericalHarmonicRecon/src/util/ ========================================================= File [modified]: ascii_output.c Delta lines: +2 -2 =================================================================== --- PITTNullCode/SphericalHarmonicRecon/src/util/ascii_output.c 2011-08-09 17:55:57 UTC (rev 54) +++ PITTNullCode/SphericalHarmonicRecon/src/util/ascii_output.c 2011-08-09 22:08:32 UTC (rev 55) @@ -88,6 +88,8 @@ }; int i; + + const int lmax = (int)(sqrt(na)+0.1) - 1; assert (rC); assert (iC); @@ -101,8 +103,6 @@ goto end; } - const int lmax = (int)(sqrt(na)+0.1) - 1; - if (l<0 || l > lmax) { fprintf(stderr, "l must be between 0 and %d\n",

1 0

[svn:einsteintoolkit] incoming/PITTNullCode/ (Rev. 54)
by yosef＠astro.rit.edu 09 Aug '11

09 Aug '11

User: zlochower Date: 2011/08/09 12:55 PM Modified: /PITTNullCode/NullDecomp/src/ Startup.F90 /PITTNullCode/NullExact/src/ NullExact_MoLRegister.c /PITTNullCode/NullGrid/src/ NullGrid_Setup.F90 /PITTNullCode/NullPsiInt/src/ NullPsiInt_MoLRegister.c /PITTNullCode/NullSHRExtract/src/ NullSHRE_Pointing.F90 /PITTNullCode/SphericalHarmonicDecomp/doc/ documentation.tex Log: -- fixes so that the code compiles with gfortran. -- fixed function prototypes for scheduled functions File Changes: Directory: /PITTNullCode/SphericalHarmonicDecomp/doc/ ===================================================== File [modified]: documentation.tex Delta lines: +1 -1 =================================================================== --- PITTNullCode/SphericalHarmonicDecomp/doc/documentation.tex 2011-08-05 12:37:09 UTC (rev 53) +++ PITTNullCode/SphericalHarmonicDecomp/doc/documentation.tex 2011-08-09 17:55:57 UTC (rev 54) @@ -160,7 +160,7 @@ in radius. Minimally, we would need the number of angular points to be equal to the number of angular spectral functions $\ell^2 + 2\ell$, in this case we have many more angular modes ($41*82$) than angular -spectral functions. Similarly num\_\x\_points must be greater than +spectral functions. Similarly num\_x\_points must be greater than num\_n\_modes. The number of n modes is set by the need to accurately model the radial derivative of the mertric functions in the spherical shell. The larger the difference between EM\_Rin[] and EM\_Rout[] the Directory: /PITTNullCode/NullDecomp/src/ ======================================== File [modified]: Startup.F90 Delta lines: +2 -1 =================================================================== --- PITTNullCode/NullDecomp/src/Startup.F90 2011-08-05 12:37:09 UTC (rev 53) +++ PITTNullCode/NullDecomp/src/Startup.F90 2011-08-09 17:55:57 UTC (rev 54) @@ -17,10 +17,11 @@ CCTK_INT :: l, m CCTK_INT :: two = 2 + TARGET:: area, kern + DECLARE_CCTK_FUNCTIONS DECLARE_CCTK_ARGUMENTS - TARGET:: area, kern DECLARE_CCTK_PARAMETERS Directory: /PITTNullCode/NullExact/src/ ======================================= File [modified]: NullExact_MoLRegister.c Delta lines: +2 -2 =================================================================== --- PITTNullCode/NullExact/src/NullExact_MoLRegister.c 2011-08-05 12:37:09 UTC (rev 53) +++ PITTNullCode/NullExact/src/NullExact_MoLRegister.c 2011-08-09 17:55:57 UTC (rev 54) @@ -13,9 +13,9 @@ static const char *rcsid = "$Header$"; -int NullExact_MoLRegister(CCTK_ARGUMENTS); +void NullExact_MoLRegister(CCTK_ARGUMENTS); -int NullExact_MoLRegister(CCTK_ARGUMENTS) +void NullExact_MoLRegister(CCTK_ARGUMENTS) { DECLARE_CCTK_ARGUMENTS; Directory: /PITTNullCode/NullGrid/src/ ====================================== File [modified]: NullGrid_Setup.F90 Delta lines: +4 -3 =================================================================== --- PITTNullCode/NullGrid/src/NullGrid_Setup.F90 2011-08-05 12:37:09 UTC (rev 53) +++ PITTNullCode/NullGrid/src/NullGrid_Setup.F90 2011-08-09 17:55:57 UTC (rev 54) @@ -9,12 +9,13 @@ use NullGrid_Vars implicit none + TARGET :: null_xb, null_xbh, stereo_q, stereo_p, stereo_pp, zeta, guard_mask, EG_mask,& + null_rb, null_rbh + + DECLARE_CCTK_ARGUMENTS DECLARE_CCTK_PARAMETERS - target :: null_xb, null_xbh, stereo_q, stereo_p, stereo_pp, zeta, guard_mask, EG_mask,& - null_rb, null_rbh - gsh = null_gsh lsh = null_lsh Directory: /PITTNullCode/NullPsiInt/src/ ======================================== File [modified]: NullPsiInt_MoLRegister.c Delta lines: +2 -2 =================================================================== --- PITTNullCode/NullPsiInt/src/NullPsiInt_MoLRegister.c 2011-08-05 12:37:09 UTC (rev 53) +++ PITTNullCode/NullPsiInt/src/NullPsiInt_MoLRegister.c 2011-08-09 17:55:57 UTC (rev 54) @@ -13,9 +13,9 @@ static const char *rcsid = "$Header$"; -int NullPsiInt_MoLRegister(CCTK_ARGUMENTS); +void NullPsiInt_MoLRegister(CCTK_ARGUMENTS); -int NullPsiInt_MoLRegister(CCTK_ARGUMENTS) +void NullPsiInt_MoLRegister(CCTK_ARGUMENTS) { DECLARE_CCTK_ARGUMENTS; Directory: /PITTNullCode/NullSHRExtract/src/ ============================================ File [modified]: NullSHRE_Pointing.F90 Delta lines: +11 -8 =================================================================== --- PITTNullCode/NullSHRExtract/src/NullSHRE_Pointing.F90 2011-08-05 12:37:09 UTC (rev 53) +++ PITTNullCode/NullSHRExtract/src/NullSHRE_Pointing.F90 2011-08-09 17:55:57 UTC (rev 54) @@ -8,10 +8,6 @@ use NullSHRE_modVars implicit none - DECLARE_CCTK_ARGUMENTS - DECLARE_CCTK_PARAMETERS - CCTK_INT :: i, j - target :: SHRE_alpha target :: SHRE_dralpha, SHRE_dqalpha, SHRE_dpalpha, SHRE_dtalpha target :: WT_detg, WT_temp, WT_sigma2, WT_elld, WT_r0, WT_r1 @@ -19,6 +15,11 @@ target :: qa_2, qa_3, x_wt, j_wt, j_l target :: beta_wt, beta_l, u_wt, u_l, q_wt, w_wt, w_l + + DECLARE_CCTK_ARGUMENTS + DECLARE_CCTK_PARAMETERS + CCTK_INT :: i, j + logical, save :: first_call = .true. if (first_call) call nullify_all @@ -149,11 +150,12 @@ use NullSHRE_modVars implicit none + TARGET :: SHRE_alpha_p, WT_r1_p + TARGET :: SHRE_dralpha_p, SHRE_dqalpha_p, SHRE_dpalpha_p, SHRE_dtalpha_p + DECLARE_CCTK_ARGUMENTS DECLARE_CCTK_PARAMETERS - target :: SHRE_alpha_p, WT_r1_p - target :: SHRE_dralpha_p, SHRE_dqalpha_p, SHRE_dpalpha_p, SHRE_dtalpha_p call NullSHRE_Pointing(CCTK_PASS_FTOF) @@ -206,11 +208,12 @@ use NullSHRE_modVars implicit none + TARGET :: SHRE_alpha_p_p, WT_r1_p_p + TARGET :: SHRE_dralpha_p_p, SHRE_dqalpha_p_p, SHRE_dpalpha_p_p, SHRE_dtalpha_p_p + DECLARE_CCTK_ARGUMENTS DECLARE_CCTK_PARAMETERS - target :: SHRE_alpha_p_p, WT_r1_p_p - target :: SHRE_dralpha_p_p, SHRE_dqalpha_p_p, SHRE_dpalpha_p_p, SHRE_dtalpha_p_p call NullSHRE_Pointing(CCTK_PASS_FTOF)

1 0

[svn:einsteintoolkit] SetMask_SphericalSurface/trunk/ (Rev. 111)
by roland.haas＠physics.gatech.edu 09 Aug '11

09 Aug '11

User: rhaas Date: 2011/08/09 08:03 AM Modified: /trunk/ param.ccl Log: make mask parameters steerable in case one finds that the excision regions is too small File Changes: Directory: /trunk/ ================== File [modified]: param.ccl Delta lines: +3 -3 =================================================================== --- trunk/param.ccl 2011-04-21 04:47:03 UTC (rev 110) +++ trunk/param.ccl 2011-08-09 13:03:08 UTC (rev 111) @@ -1,6 +1,6 @@ # Parameter definitions for thorn SetMask_SphericalSurface -STRING SetMask_MaskName "Full variable name of the mask to be set" +STRING SetMask_MaskName "Full variable name of the mask to be set" STEERABLE=always { ".+" :: "Any full Cactus variable name, GF of type CCTK_BYTE" } "HydroBase::hydro_excision_mask" @@ -9,12 +9,12 @@ #{ #} "yes" -CCTK_INT SetMask_SurfaceIndex[10] "Index of spherical surface to use to set mask" +CCTK_INT SetMask_SurfaceIndex[10] "Index of spherical surface to use to set mask" STEERABLE=always { -1:* :: "-1 to disable (default), >=0 for index" } -1 -CCTK_REAL SetMask_RadiusFactor[10] "Factor to modify radius of surface for mask" +CCTK_REAL SetMask_RadiusFactor[10] "Factor to modify radius of surface for mask" STEERABLE=always { 0:* :: "Some positive factor, default: 1" } 1

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 101)
by roland.haas＠physics.gatech.edu 07 Aug '11

07 Aug '11

User: rhaas Date: 2011/08/07 08:40 PM Modified: / ET.tex Log: remove duplicate text from components/AMR section, streamsline Boundary section originally the idea was to merge the AMR section into the core components AMR section. This would have increased the length of that section quite a bit and provided much more details than the current high level description. CarpetRegrid seems to be better off in the components sections rather than insdie the AMR section. File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +28 -59 =================================================================== --- ET.tex 2011-08-05 17:54:46 UTC (rev 100) +++ ET.tex 2011-08-08 01:40:52 UTC (rev 101) @@ -459,6 +459,7 @@ world-wide. To date, more than 90 peer-reviewed publication and more than 15 student theses are based on Carpet \cite{CarpetCode:web}. + \subsection{Simulation Factory\pagesdone{1 Erik}} Today's supercomputers differ significantly in @@ -1757,12 +1758,12 @@ boundary or symmetry conditions. \subsubsection{Symmetries, Boundary Conditions.} -The Einstein Toolkit includes a set of thorns, \codename{Boundary} +The Einstein Toolkit includes two thorns, \codename{Boundary} and \codename{SymBase}, to provide a generic interface to specify and implement boundary and symmetry conditions. -For symmetry conditions the toolkit includes built-in suppport for a +The toolkit includes built-in suppport for a set of reflecting or rotating symmetry conditions that can be used to reduce the size of the simulation @@ -1770,10 +1771,10 @@ directions (via the \codename{Periodic} module), reflections across the coordinate planes (via the \codename{Reflection} module), -$90^{\circ}$ and $180^{\circ}$ rotational +$90^{\circ}$ and $180^{\circ}$ rotational symmetries (via the \codename{RotatingSymmetry90} and \codename{RotatingSymmetry180} modules respectively) -symmetries about the $z$ axis, and a continuous rotational symmetry (via +about the $z$ axis, and a continuous rotational symmetry (via the \codename{Cartoon2D} thorn)~\cite{Alcubierre:1999ab}. \codename{Cartoon2D} allows fully three dimensional codes to be used in axissymmtric problems by evolving @@ -1814,44 +1815,20 @@ \label{fig:faces} \end{figure} -Thorn \codename{Boundary} provides basic physical boundary conditions. -A boundary -condition suitable for matter fields which approach a constant -(atmosphere) value on the boundary is provided via either the ``flat'' -or ``scalar'' -(Dirichlet) boundary conditions. These boundary conditions set the -values on the boundary to either those close by in the direction of the -normal to the boundary (``flat'') or to a fixed given value -(``scalar''). -The ``copy'' boundary condition uses a secondary grid variable to fill -in the boundary values, allowing arbitrary boundary conditions to be -imposed. -\codename{Boundary} provides a fall-off (``Robin'') boundary condition -suitable for fields -whose behaviour near the boundary is described by -\begin{equation} - f(r) = f_0 + \frac{k}{r^n}\text{,} - \label{eqn:robin-falloff} -\end{equation} -for a given decay rate $n$, value at infinity $f_0$ and scaling constant -$k$. $r$ is taken to be the coordinate distance perpendicular to the -domain boundary under consideration when the boundary condition is -applied. One example of this type of boundary condition is described -in section~\ref{sec:curv_boundaries}. -Radiative (Sommerfeld) and extrapolation -boundary conditions are provided by thorn \codename{NewRad}. +Thorn \codename{Boundary} serves as a registry for available boundary +conditions and provides basic scheduling to enforce all requested +boundary conditions at the proper times. It also provides a basic set of +boundary conditions to be used by user thorn. The ``flat'' boundary +conditions often used for hydrodynamic variables that approach an +atmosphere value fall in this category. More complicated boundary +conditions are often implemented as modifications to the evolution +equations and are not handled directly by \codename{Boundary}. The +radiative (Sommerfeld) and extrapolation boundary conditions provided by +thorn \codename{NewRad} are of this kind. \subsubsection{Adaptive Mesh Refinement} -\todo{Move this to 4.2 (and merge it with that)} -The \codename{Carpet} driver thorn provides adaptive mesh refinement -optionally using subcycling in time and level-dependend spatial -refinement factors as well as -Multi-Block capabilities to thorns in the Einstein Toolkit. As in most -adaptive mesh refinement frameworks, care has been taken to separate -driver related code from physics codes. A typical evolution or analysis -code like \codename{McLachlan} or \codename{WeylScal4} is agnostic to -the mesh refinement. -\codename{Carpet} supports feature-based mesh refinement, which is +The Einstein toolkit currently supports feature-based mesh refinement, +which is based on extracting e.g.\ the locations of black holes or neutron stars, and then constructing a mesh hierarchy (stacks of refined regions) based @@ -1863,7 +1840,8 @@ such a grid. If initial conditions are constructed outside of Carpet (which is often the case), then the initial mesh hierarchy has to be defined manually. -The Einstein toolkit currently provides two regridding modules in +In order to fascilate the description of the mesh hierarchy the\ +Einstein toolkit provides two regridding modules in the \codename{CarpetRegrid} and \codename{CarpetRegrid2} thorns. Both thorns primarily support box-in-box type refined meshes, which is well suited to current binary black hole simulations in which the @@ -1884,19 +1862,20 @@ \end{figure} \codename{CarpetRegrid} provides a number of different ways to specify -the refined regions, either as a set of boxes centered around the origin -or as an explicit list of boxes that make up the grid hierarchy. +the refined regions, e.g. as a set of boxes centered around the origin +or as an explicit list of regions that make up the grid hierarchy. Traditionally groups using \codename{CarpetRegrid} have employed auxiliary thorns, that are not part of the Einstein Toolkit, to create this list of boxes based on information obtained e.g.\ from apparent horizon tracking. \codename{CarpetRegrid2} provides a user friendly interface to define sets of nested boxes that follow black holes or -other tracked objects. \codename{CarpetRegrid2} supports up to 10 sets -of nested boxes which can be either moving or stationary. The number -of refinement levels in each set of boxes as well as the radii of each -nested -box are allowed to change during runtime, making it possible to e.g.\ -adapt the shape of the refined region to the surface of a star. +other tracked objects. +Object coordinates are updated by +\codename{CarpetTracker} which provides a simple interface to +the object trackers +\codename{PunctureTracker} and \codename{NSTracker} (see +section~\ref{sec:object-tracking}) to have the refined region follow +the moving objects. \codename{CarpetRegrid2} contains code to handle the $\pi$-symmetry provided by \codename{RotatingSymmetry180}, enforcing the symmetry on the resulting grid layout (see Figure~\ref{fig:rot180-grid}). @@ -1920,16 +1899,6 @@ \label{fig:rot180-grid} \end{figure} -\codename{CarpetTracker} provides a simple interface to slave -\codename{CarpetRegrid2}'s regions to the object trackers -\codename{PunctureTracker} and \codename{NSTracker} (see -section~\ref{sec:object-tracking}) by copying the position of tracked -objects -from a \codename{SphericalSurface} into -\codename{CarpetRegrid2}. - - - \section{Examples\pages{0.5 Frank}} \todo{Will be written once we know which examples we have}

1 0

[svn:einsteintoolkit] GRHydro/trunk/ (Rev. 264)
by roland.haas＠physics.gatech.edu 05 Aug '11

05 Aug '11

User: rhaas Date: 2011/08/05 01:07 PM Modified: /trunk/ schedule.ccl Log: re-add update of Tmunu after AtmosphereReset, fix typo in routine name File Changes: Directory: /trunk/ ================== File [modified]: schedule.ccl Delta lines: +9 -3 =================================================================== --- trunk/schedule.ccl 2011-08-04 17:05:23 UTC (rev 263) +++ trunk/schedule.ccl 2011-08-05 18:07:18 UTC (rev 264) @@ -967,8 +967,10 @@ ### If a point has been marked as requiring resetting to the ### ### atmosphere, this is where we do it. ### ### ### -### You didn't see this abuse of MoL. Nothing to see here, ### -### move along. ### +### This is logically still part of the MoL evolution step ### +### since it is part of evolving the primitives. The final ### +### SetTmunu should be before PseudoEvolution so that eg. ### +### constraints use the correct stress energy tensor. ### ################################################################ if (CCTK_Equals(Bvec_evolution_method,"GRHydro")) @@ -984,10 +986,14 @@ } "Reset the atmosphere" } -schedule group HydroBase_Boundaries AT EVOL AFTER MoL_Evolution AFTER (GRHydro_AtmosphereRese GRHydro_AtmosphereResetM) +schedule group HydroBase_Boundaries AT EVOL AFTER MoL_Evolution AFTER (GRHydro_AtmosphereReset GRHydro_AtmosphereResetM) { } "HydroBase Boundary conditions group" +schedule GROUP SetTmunu AT EVOL AFTER HydroBase_Boundaries BEFORE MoL_PseudoEvolution +{ +} "Calculate the stress-energy tensor" + } # end of if (CCTK_EQUALS(hydrobase::evolution_method, "GRHydro")) if (set_trivial_rp_grid_function)

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 100)
by bcmsma＠astro.rit.edu 05 Aug '11

05 Aug '11

User: bmundim Date: 2011/08/05 12:54 PM Modified: / ET.tex Log: Josh's updates to the paper Some big changes to intro, to bring it up to date, more minor stuff for Secs. 2 and 3. GRhydro section revision underway. Many updates to the main bibfile in manifest. TODO: one of the Christian's, or someone with similar experience, needs to review the core collapse/neutron star oscillation text in the intro. File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: <Unavailable>

1 0

[svn:einsteintoolkit] incoming/PITTNullCode/SphericalHarmonicRecon/ (Rev. 53)
by yosef＠astro.rit.edu 05 Aug '11

05 Aug '11

User: zlochower Date: 2011/08/05 07:37 AM Modified: /PITTNullCode/SphericalHarmonicRecon/ configuration.ccl Log: Missing dependency on FFTW3 added. File Changes: Directory: /PITTNullCode/SphericalHarmonicRecon/ ================================================ File [modified]: configuration.ccl Delta lines: +1 -1 =================================================================== --- PITTNullCode/SphericalHarmonicRecon/configuration.ccl 2011-08-05 02:32:04 UTC (rev 52) +++ PITTNullCode/SphericalHarmonicRecon/configuration.ccl 2011-08-05 12:37:09 UTC (rev 53) @@ -1 +1 @@ -REQUIRES HDF5 +REQUIRES HDF5 FFTW3

1 0

[svn:einsteintoolkit] incoming/PITTNullCode/FFTW3/ (Rev. 52)
by knarf＠cct.lsu.edu 04 Aug '11

04 Aug '11

User: knarf Date: 2011/08/04 09:32 PM Removed: /PITTNullCode/FFTW3/ Log: thorn now lives in https://svn.cactuscode.org/projects/ExternalLibraries/FFTW3/

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Commits August 2011