Commits August 2011

commits@lists.einsteintoolkit.org

9 participants
99 discussions

[svn:einsteintoolkit] GRHydro/trunk/src/ (Rev. 256)
by cott＠tapir.caltech.edu 02 Aug '11

02 Aug '11

User: cott Date: 2011/08/02 01:52 PM Modified: /trunk/src/ GRHydro_ENOReconstruct_drv.F90, GRHydro_PPMMReconstruct_drv.F90, GRHydro_PPMReconstruct_drv.F90, GRHydro_Reconstruct.F90, GRHydro_TVDReconstruct_drv.F90 Log: * modify reconstruction: * get rid of nonsensical re-computation of the conserved tracer * remove support for shift_state = 0 and get rid of unnecessary assignments. File Changes: Directory: /trunk/src/ ====================== File [modified]: GRHydro_ENOReconstruct_drv.F90 Delta lines: +5 -24 =================================================================== --- trunk/src/GRHydro_ENOReconstruct_drv.F90 2011-08-02 06:31:44 UTC (rev 255) +++ trunk/src/GRHydro_ENOReconstruct_drv.F90 2011-08-02 18:52:56 UTC (rev 256) @@ -1,7 +1,7 @@ /*@@ @file GRHydro_ENOReconstruct_drv.F90 @date Tue Jul 19 13:22:03 EDT 2011 - @author Bruno C. Mundim, Joshua Faber + @author Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc Driver routine to perform the ENO reconstruction. @enddesc @@ -31,7 +31,7 @@ /*@@ @routine GRHydro_ENOReconstruct_drv @date Tue Jul 19 13:24:34 EDT 2011 - @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber + @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc A driver routine to do ENO reconstruction. @enddesc @@ -54,16 +54,13 @@ integer :: nx, ny, nz, i, j, k, itracer logical, dimension(:,:,:), allocatable :: trivial_rp -!!$ logical, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: trivial_rp CCTK_INT :: type_bitsx, trivialx, not_trivialx, & &type_bitsy, trivialy, not_trivialy, & &type_bitsz, trivialz, not_trivialz CCTK_REAL, dimension(:,:,:),allocatable :: & - &psi4, lbetax, lbetay, lbetaz, dum, dump, dumm -!!$ CCTK_REAL, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: & -!!$ &psi4, lbetax, lbetay, lbetaz + &dum, dump, dumm CCTK_INT :: ierr @@ -73,16 +70,12 @@ end if !!$ The dum variables are used as dummies if MHD on but divergence cleaning off - allocate(psi4(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetax(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetay(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetaz(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - dum(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& + allocate(dum(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& dump(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& dumm(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),STAT=ierr) if (ierr .ne. 0) then - call CCTK_WARN(0, "Allocation problems with lbeta") + call CCTK_WARN(0, "Allocation problems with dum dump dumm") end if call SpaceMask_GetTypeBits(type_bitsx, "Hydro_RiemannProblemX") @@ -112,7 +105,6 @@ do j=1,cctk_lsh(2) do i=1,cctk_lsh(1) trivial_rp(i,j,k) = .false. - psi4(i,j,k) = 1.0d0 rhoplus(i,j,k) = 0.0d0 rhominus(i,j,k)= 0.0d0 epsplus(i,j,k) = 0.0d0 @@ -147,16 +139,6 @@ Y_e_minus(i,j,k) = 0.0d0 endif - if (shift_state .ne. 0) then - lbetax(i,j,k) = betax(i,j,k) - lbetay(i,j,k) = betay(i,j,k) - lbetaz(i,j,k) = betaz(i,j,k) - else - lbetax(i,j,k) = 0.d0 - lbetay(i,j,k) = 0.d0 - lbetaz(i,j,k) = 0.d0 - end if - enddo enddo enddo @@ -425,7 +407,6 @@ !!$ ENO ends. deallocate(trivial_rp) - deallocate(psi4, lbetax, lbetay, lbetaz) deallocate(dum,dump,dumm) end subroutine GRHydro_ENOReconstruct_drv File [modified]: GRHydro_PPMMReconstruct_drv.F90 Delta lines: +10 -33 =================================================================== --- trunk/src/GRHydro_PPMMReconstruct_drv.F90 2011-08-02 06:31:44 UTC (rev 255) +++ trunk/src/GRHydro_PPMMReconstruct_drv.F90 2011-08-02 18:52:56 UTC (rev 256) @@ -1,7 +1,7 @@ /*@@ @file GRHydro_PPMMReconstruct_drv.F90 @date Wed Jul 27 15:17:03 EDT 2011 - @author Bruno C. Mundim, Joshua Faber + @author Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc Driver routine to perform the magnetic version of PPM reconstruction. @enddesc @@ -31,7 +31,7 @@ /*@@ @routine GRHydro_PPMMReconstruct_drv @date Wed Jul 27 15:17:55 EDT 2011 - @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber + @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc A driver routine to do magnetic version of PPM reconstructions. @enddesc @@ -54,16 +54,13 @@ integer :: nx, ny, nz, i, j, k, itracer logical, dimension(:,:,:), allocatable :: trivial_rp -!!$ logical, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: trivial_rp CCTK_INT :: type_bitsx, trivialx, not_trivialx, & &type_bitsy, trivialy, not_trivialy, & &type_bitsz, trivialz, not_trivialz CCTK_REAL, dimension(:,:,:),allocatable :: & - &psi4, lbetax, lbetay, lbetaz, dum, dump, dumm -!!$ CCTK_REAL, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: & -!!$ &psi4, lbetax, lbetay, lbetaz + dum, dump, dumm CCTK_INT :: ierr @@ -73,18 +70,10 @@ end if !!$ The dum variables are used as dummies if MHD on but divergence cleaning off - allocate(psi4(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetax(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetay(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetaz(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - dum(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& + allocate(dum(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& dump(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& dumm(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),STAT=ierr) - if (ierr .ne. 0) then - call CCTK_WARN(0, "Allocation problems with lbeta") - end if - call SpaceMask_GetTypeBits(type_bitsx, "Hydro_RiemannProblemX") call SpaceMask_GetStateBits(trivialx, "Hydro_RiemannProblemX", & &"trivial") @@ -112,7 +101,6 @@ do j=1,cctk_lsh(2) do i=1,cctk_lsh(1) trivial_rp(i,j,k) = .false. - psi4(i,j,k) = 1.0d0 rhoplus(i,j,k) = 0.0d0 rhominus(i,j,k)= 0.0d0 epsplus(i,j,k) = 0.0d0 @@ -145,16 +133,6 @@ Y_e_minus(i,j,k) = 0.0d0 endif - if (shift_state .ne. 0) then - lbetax(i,j,k) = betax(i,j,k) - lbetay(i,j,k) = betay(i,j,k) - lbetaz(i,j,k) = betaz(i,j,k) - else - lbetax(i,j,k) = 0.d0 - lbetay(i,j,k) = 0.d0 - lbetaz(i,j,k) = 0.d0 - end if - enddo enddo enddo @@ -175,7 +153,7 @@ Bvecxplus(:,j,k),Bvecyplus(:,j,k),Bveczplus(:,j,k),psidcplus(:,j,k),epsplus(:,j,k),& 1,trivial_rp(:,j,k), hydro_excision_mask(:,j,k),& gxx(:,j,k), gxy(:,j,k), gxz(:,j,k), gyy(:,j,k), gyz(:,j,k), & - gzz(:,j,k), psi4(:,j,k), lbetax(:,j,k), alp(:,j,k),& + gzz(:,j,k), betax(:,j,k), alp(:,j,k),& w_lorentz(:,j,k), & 1, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_x_left, & GRHydro_mppm_eigenvalue_x_right, & @@ -190,7 +168,7 @@ Bvecxplus(:,j,k),Bvecyplus(:,j,k),Bveczplus(:,j,k),dump(:,j,k),epsplus(:,j,k),& 0,trivial_rp(:,j,k), hydro_excision_mask(:,j,k),& gxx(:,j,k), gxy(:,j,k), gxz(:,j,k), gyy(:,j,k), gyz(:,j,k), & - gzz(:,j,k), psi4(:,j,k), lbetax(:,j,k), alp(:,j,k),& + gzz(:,j,k), betax(:,j,k), alp(:,j,k),& w_lorentz(:,j,k), & 1, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_x_left, & GRHydro_mppm_eigenvalue_x_right, & @@ -246,7 +224,7 @@ Bvecyplus(j,:,k),Bveczplus(j,:,k),Bvecxplus(j,:,k),psidcplus(j,:,k),epsplus(j,:,k),& 1,trivial_rp(j,:,k), hydro_excision_mask(j,:,k),& gyy(j,:,k), gyz(j,:,k), gxy(j,:,k), gzz(j,:,k), gxz(j,:,k), & - gxx(j,:,k), psi4(j,:,k), lbetay(j,:,k), alp(j,:,k),& + gxx(j,:,k), betay(j,:,k), alp(j,:,k),& w_lorentz(j,:,k), & 2, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_y_left, & GRHydro_mppm_eigenvalue_y_right, & @@ -261,7 +239,7 @@ Bvecyplus(j,:,k),Bveczplus(j,:,k),Bvecxplus(j,:,k),dump(j,:,k),epsplus(j,:,k),& 0,trivial_rp(j,:,k), hydro_excision_mask(j,:,k),& gyy(j,:,k), gyz(j,:,k), gxy(j,:,k), gzz(j,:,k), gxz(j,:,k), & - gxx(j,:,k), psi4(j,:,k), lbetay(j,:,k), alp(j,:,k),& + gxx(j,:,k), betay(j,:,k), alp(j,:,k),& w_lorentz(j,:,k), & 2, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_y_left, & GRHydro_mppm_eigenvalue_y_right, & @@ -316,7 +294,7 @@ Bveczplus(j,k,:),Bvecxplus(j,k,:),Bvecyplus(j,k,:),psidcplus(j,k,:),epsplus(j,k,:),& 1,trivial_rp(j,k,:), hydro_excision_mask(j,k,:),& gzz(j,k,:), gxz(j,k,:), gyz(j,k,:), gxx(j,k,:), gxy(j,k,:), & - gyy(j,k,:), psi4(j,k,:), lbetaz(j,k,:), alp(j,k,:),& + gyy(j,k,:), betaz(j,k,:), alp(j,k,:),& w_lorentz(j,k,:), & 3, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_z_left, & GRHydro_mppm_eigenvalue_z_right, & @@ -331,7 +309,7 @@ Bveczplus(j,k,:),Bvecxplus(j,k,:),Bvecyplus(j,k,:),dump(j,k,:),epsplus(j,k,:),& 0,trivial_rp(j,k,:), hydro_excision_mask(j,k,:),& gzz(j,k,:), gxz(j,k,:), gyz(j,k,:), gxx(j,k,:), gxy(j,k,:), & - gyy(j,k,:), psi4(j,k,:), lbetaz(j,k,:), alp(j,k,:),& + gyy(j,k,:), betaz(j,k,:), alp(j,k,:),& w_lorentz(j,k,:), & 3, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_z_left, & GRHydro_mppm_eigenvalue_z_right, & @@ -379,7 +357,6 @@ !!$ PPM ends. deallocate(trivial_rp) - deallocate(psi4, lbetax, lbetay, lbetaz) deallocate(dum,dump,dumm) end subroutine GRHydro_PPMMReconstruct_drv File [modified]: GRHydro_PPMReconstruct_drv.F90 Delta lines: +6 -34 =================================================================== --- trunk/src/GRHydro_PPMReconstruct_drv.F90 2011-08-02 06:31:44 UTC (rev 255) +++ trunk/src/GRHydro_PPMReconstruct_drv.F90 2011-08-02 18:52:56 UTC (rev 256) @@ -1,7 +1,7 @@ /*@@ @file GRHydro_PPMReconstruct_drv.F90 @date Tue Jul 19 13:22:03 EDT 2011 - @author Bruno C. Mundim, Joshua Faber + @author Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc Driver routine to perform the PPM reconstructions. @enddesc @@ -25,7 +25,7 @@ /*@@ @routine GRHydro_PPMReconstruct_drv @date Tue Jul 19 13:24:34 EDT 2011 - @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber + @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc A driver routine to do PPM reconstructions. @enddesc @@ -48,34 +48,18 @@ integer :: nx, ny, nz, i, j, k, itracer logical, dimension(:,:,:), allocatable :: trivial_rp -!!$ logical, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: trivial_rp CCTK_INT :: type_bitsx, trivialx, not_trivialx, & &type_bitsy, trivialy, not_trivialy, & &type_bitsz, trivialz, not_trivialz - CCTK_REAL, dimension(:,:,:),allocatable :: & - &psi4, lbetax, lbetay, lbetaz -!!$ CCTK_REAL, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: & -!!$ &psi4, lbetax, lbetay, lbetaz - CCTK_INT :: ierr allocate(trivial_rp(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),STAT=ierr) if (ierr .ne. 0) then call CCTK_WARN(0, "Allocation problems with trivial_rp") end if - - allocate(psi4(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetax(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetay(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetaz(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - STAT=ierr) - - if (ierr .ne. 0) then - call CCTK_WARN(0, "Allocation problems with psi4 or lbeta") - end if - + call SpaceMask_GetTypeBits(type_bitsx, "Hydro_RiemannProblemX") call SpaceMask_GetStateBits(trivialx, "Hydro_RiemannProblemX", & &"trivial") @@ -103,7 +87,6 @@ do j=1,cctk_lsh(2) do i=1,cctk_lsh(1) trivial_rp(i,j,k) = .false. - psi4(i,j,k) = 1.0d0 rhoplus(i,j,k) = 0.0d0 rhominus(i,j,k)= 0.0d0 epsplus(i,j,k) = 0.0d0 @@ -125,16 +108,6 @@ Y_e_minus(i,j,k) = 0.0d0 endif - if (shift_state .ne. 0) then - lbetax(i,j,k) = betax(i,j,k) - lbetay(i,j,k) = betay(i,j,k) - lbetaz(i,j,k) = betaz(i,j,k) - else - lbetax(i,j,k) = 0.d0 - lbetay(i,j,k) = 0.d0 - lbetaz(i,j,k) = 0.d0 - end if - enddo enddo enddo @@ -153,7 +126,7 @@ velxplus(:,j,k),velyplus(:,j,k),velzplus(:,j,k),epsplus(:,j,k),& trivial_rp(:,j,k), hydro_excision_mask(:,j,k),& gxx(:,j,k), gxy(:,j,k), gxz(:,j,k), gyy(:,j,k), gyz(:,j,k), & - gzz(:,j,k), psi4(:,j,k), lbetax(:,j,k), alp(:,j,k),& + gzz(:,j,k), betax(:,j,k), alp(:,j,k),& w_lorentz(:,j,k), & 1, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_x_left, & GRHydro_mppm_eigenvalue_x_right, & @@ -204,7 +177,7 @@ velyplus(j,:,k),velzplus(j,:,k),velxplus(j,:,k),epsplus(j,:,k),& trivial_rp(j,:,k), hydro_excision_mask(j,:,k),& gyy(j,:,k), gyz(j,:,k), gxy(j,:,k), gzz(j,:,k), gxz(j,:,k), & - gxx(j,:,k), psi4(j,:,k), lbetay(j,:,k), alp(j,:,k),& + gxx(j,:,k), betay(j,:,k), alp(j,:,k),& w_lorentz(j,:,k), & 2, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_y_left, & GRHydro_mppm_eigenvalue_y_right, & @@ -255,7 +228,7 @@ velzplus(j,k,:),velxplus(j,k,:),velyplus(j,k,:),epsplus(j,k,:),& trivial_rp(j,k,:), hydro_excision_mask(j,k,:),& gzz(j,k,:), gxz(j,k,:), gyz(j,k,:), gxx(j,k,:), gxy(j,k,:), & - gyy(j,k,:), psi4(j,k,:), lbetaz(j,k,:), alp(j,k,:),& + gyy(j,k,:), betaz(j,k,:), alp(j,k,:),& w_lorentz(j,k,:), & 3, j, k, nx, ny, nz, GRHydro_mppm_eigenvalue_z_left, & GRHydro_mppm_eigenvalue_z_right, & @@ -302,7 +275,6 @@ !!$ PPM ends. deallocate(trivial_rp) - deallocate(psi4, lbetax, lbetay, lbetaz) end subroutine GRHydro_PPMReconstruct_drv File [modified]: GRHydro_Reconstruct.F90 Delta lines: +6 -8 =================================================================== --- trunk/src/GRHydro_Reconstruct.F90 2011-08-02 06:31:44 UTC (rev 255) +++ trunk/src/GRHydro_Reconstruct.F90 2011-08-02 18:52:56 UTC (rev 256) @@ -1,7 +1,7 @@ /*@@ @file GRHydro_Reconstruct.F90 @date Sat Jan 26 02:13:25 2002 - @author + @author Bruno Mundim, Josh Faber, Christian D. Ott @desc Wrapper routine to perform the reconstruction. @enddesc @@ -17,7 +17,7 @@ /*@@ @routine Reconstruction @date Sat Jan 26 02:13:47 2002 - @author Luca Baiotti, Ian Hawke + @author Luca Baiotti, Ian Hawke, Christian D. Ott @desc A wrapper routine to do reconstruction. Currently just does TVD on the primitive variables. @@ -41,6 +41,10 @@ CCTK_INT :: i,j,k CCTK_REAL :: local_min_tracer + ! set things up + if (shift_state .eq. 0) then + call CCTK_WARN(0,"This code no longer supports shift_state = 0"); + endif if (CCTK_EQUALS(recon_method,"tvd")) then ! this handles MHD and non-MHD @@ -116,12 +120,6 @@ call CCTK_WARN(0,"Variable type to reconstruct not recognized.") end if - if(evolve_tracer.ne.0) then - ! Call the conserved tracer routine in any case because (accord. to - ! Christian Ott) this is the only way this works - call Prim2ConservativeTracer(CCTK_PASS_FTOF) - end if - return end subroutine Reconstruction File [modified]: GRHydro_TVDReconstruct_drv.F90 Delta lines: +2 -30 =================================================================== --- trunk/src/GRHydro_TVDReconstruct_drv.F90 2011-08-02 06:31:44 UTC (rev 255) +++ trunk/src/GRHydro_TVDReconstruct_drv.F90 2011-08-02 18:52:56 UTC (rev 256) @@ -1,7 +1,7 @@ /*@@ @file GRHydro_TVDReconstruct_drv.F90 @date Tue Jul 19 13:22:03 EDT 2011 - @author Bruno C. Mundim, Joshua Faber + @author Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc Driver routine to perform the TVD reconstruction. @enddesc @@ -31,7 +31,7 @@ /*@@ @routine GRHydro_TVDReconstruct_drv @date Tue Jul 19 13:24:34 EDT 2011 - @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber + @author Luca Baiotti, Ian Hawke, Bruno C. Mundim, Joshua Faber, Christian D. Ott @desc A driver routine to do TVD reconstruction. Currently just does TVD on the primitive variables. @@ -55,17 +55,11 @@ integer :: nx, ny, nz, i, j, k, itracer logical, dimension(:,:,:), allocatable :: trivial_rp -!!$ logical, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: trivial_rp CCTK_INT :: type_bitsx, trivialx, not_trivialx, & &type_bitsy, trivialy, not_trivialy, & &type_bitsz, trivialz, not_trivialz - CCTK_REAL, dimension(:,:,:),allocatable :: & - &psi4, lbetax, lbetay, lbetaz -!!$ CCTK_REAL, dimension(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)) :: & -!!$ &psi4, lbetax, lbetay, lbetaz - CCTK_INT :: ierr allocate(trivial_rp(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),STAT=ierr) @@ -73,16 +67,6 @@ call CCTK_WARN(0, "Allocation problems with trivial_rp") end if - allocate(psi4(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetax(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetay(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - lbetaz(cctk_lsh(1),cctk_lsh(2),cctk_lsh(3)),& - STAT=ierr) - - if (ierr .ne. 0) then - call CCTK_WARN(0, "Allocation problems with lbeta") - end if - call SpaceMask_GetTypeBits(type_bitsx, "Hydro_RiemannProblemX") call SpaceMask_GetStateBits(trivialx, "Hydro_RiemannProblemX", & &"trivial") @@ -110,7 +94,6 @@ do j=1,cctk_lsh(2) do i=1,cctk_lsh(1) trivial_rp(i,j,k) = .false. - psi4(i,j,k) = 1.0d0 rhoplus(i,j,k) = 0.0d0 rhominus(i,j,k)= 0.0d0 epsplus(i,j,k) = 0.0d0 @@ -145,16 +128,6 @@ Y_e_minus(i,j,k) = 0.0d0 endif - if (shift_state .ne. 0) then - lbetax(i,j,k) = betax(i,j,k) - lbetay(i,j,k) = betay(i,j,k) - lbetaz(i,j,k) = betaz(i,j,k) - else - lbetax(i,j,k) = 0.d0 - lbetay(i,j,k) = 0.d0 - lbetaz(i,j,k) = 0.d0 - end if - enddo enddo enddo @@ -255,7 +228,6 @@ !!$ TVD ends. deallocate(trivial_rp) - deallocate(psi4, lbetax, lbetay, lbetaz) end subroutine GRHydro_TVDReconstruct_drv

1 0

[svn:einsteintoolkit] GRHydro/trunk/ (Rev. 255)
by bcmsma＠astro.rit.edu 01 Aug '11

01 Aug '11

User: bmundim Date: 2011/08/02 01:31 AM Added: /trunk/src/ GRHydro_PPMMReconstruct_drv.F90 Modified: /trunk/ interface.ccl, param.ccl, schedule.ccl /trunk/src/ GRHydro_ENOReconstruct_drv.F90, GRHydro_HLLEM.F90, GRHydro_PPMReconstruct_drv.F90, GRHydro_ParamCheck.F90, GRHydro_Reconstruct.F90, GRHydro_TVDReconstruct_drv.F90, make.code.defn Log: RIT GRMHD dev: 1) Further splitting of PPM Reconstruction routine into magnetic and non-magnetic part. 2) Merge the divergence cleaning loop into the non-divergence one, since profiling indicated no substantial difference between the two cases. Indeed it was a little bit better after the merger (0.14%), but that it is not significant. We decided then to apply Occam's razor and choose the simplest form. Branch prediction seems to work fine in this case. 3) Move reconstruction initialization statements to their repective drivers. 4) Get rid of WORKSHARE in the reconstruction routines. Profiling showed a 4.16% performance improvement for the hydro ppm reconstruction routine when using 1 processor and 2 threads only. Expect a better improvement for a larger number of threads. 5) Introduce a parameter to control characteristic speeds for psidc in HLLE. File Changes: Directory: /trunk/src/ ====================== File [modified]: GRHydro_ENOReconstruct_drv.F90 Delta lines: <Unavailable> File [modified]: GRHydro_HLLEM.F90 Delta lines: <Unavailable> File [added]: GRHydro_PPMMReconstruct_drv.F90 Delta lines: <Unavailable> File [modified]: GRHydro_PPMReconstruct_drv.F90 Delta lines: <Unavailable> File [modified]: GRHydro_ParamCheck.F90 Delta lines: <Unavailable> File [modified]: GRHydro_Reconstruct.F90 Delta lines: <Unavailable> File [modified]: GRHydro_TVDReconstruct_drv.F90 Delta lines: <Unavailable> File [modified]: make.code.defn Delta lines: <Unavailable> Directory: /trunk/ ================== File [modified]: interface.ccl Delta lines: <Unavailable> File [modified]: param.ccl Delta lines: <Unavailable> File [modified]: schedule.ccl Delta lines: <Unavailable>

1 0

[svn:einsteintoolkit] manifest/trunk/ (Rev. 100)
by knarf＠cct.lsu.edu 01 Aug '11

01 Aug '11

User: knarf Date: 2011/08/01 07:43 PM Modified: /trunk/ einsteintoolkit.th Log: let GetComponents save the thornlist File Changes: Directory: /trunk/ ================== File [modified]: einsteintoolkit.th Delta lines: +1 -1 =================================================================== --- trunk/einsteintoolkit.th 2011-07-17 16:20:49 UTC (rev 99) +++ trunk/einsteintoolkit.th 2011-08-02 00:43:15 UTC (rev 100) @@ -7,9 +7,9 @@ !DEFINE ROOT = Cactus !DEFINE ARR = $ROOT/arrangements +!DEFINE COMPONENTLIST_TARGET = $ROOT/thornlists/ - # This thorn list !TARGET = $ROOT !TYPE = svn

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/examples/kerr/ (Rev. 99)
by diener＠cct.lsu.edu 01 Aug '11

01 Aug '11

User: diener Date: 2011/08/01 11:10 AM Added: /examples/kerr/ by-a0.7-hi.par, by-a0.7-med.par, by-a0.7.par Log: Parameter files for spinning distorted black hole. File Changes: Directory: /examples/kerr/ ========================== File [added]: by-a0.7-hi.par Delta lines: <Unavailable> File [added]: by-a0.7-med.par Delta lines: <Unavailable> File [added]: by-a0.7.par Delta lines: <Unavailable>

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 98)
by knarf＠cct.lsu.edu 01 Aug '11

01 Aug '11

User: knarf Date: 2011/08/01 11:06 AM Modified: / ET.tex Log: get some of the structure of the evolution methods straight File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +5 -6 =================================================================== --- ET.tex 2011-08-01 15:50:41 UTC (rev 97) +++ ET.tex 2011-08-01 16:05:59 UTC (rev 98) @@ -966,9 +966,8 @@ one may also apply a uniform velocity to the neutron star, though this does not affect the ODE solution nor the resulting density profile. -\subsection{Spacetime Curvature Evolution} +\subsection{Spacetime Curvature Evolution}\todo{Peter: move} \label{sec:evol} -\todo{Josh and Christian in charge} In the following, we assume that the reader is familiar with the basics of numerical relativity and GR hydrodynamics. Detailed @@ -1004,7 +1003,7 @@ the relativistic specific enthalpy with $\epsilon$ and $P$ being the specific internal energy and the pressure, respectively. -\subsubsection{Spacetime Curvature Evolution} +\subsection{Spacetime Curvature Evolution} \label{sec:Kevol} The Einstein Toolkit curvature evolution code \codename{McLachlan}~\cite{brown:09,reisswig:11ccwave} is @@ -1173,7 +1172,7 @@ -\paragraph{Initial Conditions} +\subsubsection{Initial Conditions} Initial conditions from the ADM variables $g_{ij}$, $K_{ij}$, lapse $\alpha$, and shift $\beta^i$, as provided by the initial data @@ -1197,7 +1196,7 @@ then defined via the points in the interior and the previously calculated layers. -\paragraph{Boundary Conditions} +\subsubsection{Boundary Conditions} \label{sec:curv_boundaries} During time evolution, a Sommerfeld-type radiative boundary condition @@ -1266,7 +1265,7 @@ gauge conditions used in \codename{McLachlan}. -\subsection{Hydrodynamics: \codename{GRHydro}}\pages{Christian and Josh} +\subsection{Hydrodynamics Evolution}\pages{Christian and Josh} \label{sec:GRHydro} {\color{red} This text is copied from Reisswig et al. It needs to be expanded a bit and we probably want to talk about the numerical methods a bit more.}

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 97)
by knarf＠cct.lsu.edu 01 Aug '11

01 Aug '11

User: knarf Date: 2011/08/01 10:50 AM Modified: / TODO Log: update todo File Changes: Directory: / ============ File [modified]: TODO Delta lines: +9 -5 =================================================================== --- TODO 2011-08-01 15:23:53 UTC (rev 96) +++ TODO 2011-08-01 15:50:41 UTC (rev 97) @@ -1,9 +1,13 @@ -someone (1) : references! - +Josh (atm) : references! Ian Hinder : Expand section on Kranc, a bit -Christian Ott: Curvature evolution looks good, but what about GRHydro? - EOS? +Christian Ott: Curvature evolution looks good +Josh : GRHydro +Christian EOS Peter : Tools not ready (puncture and star tracker, but into analysis) Roland : Merge AMR sections (4.2 and 5.8.3 currently) -Peter, Frsank, Bruno, Christian: Examples! +Peter : ready to be committed +Frank : highly perturbed ok, but slitely perturbed would be better, needs work +Bruno : data "ready" but might need some tweaks +Christian : some data is there, needs to be committed Frank : Future Work +Frank : Fix structure of 5.3

1 0

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

01 Aug '11

User: cott Date: 2011/08/01 10:23 AM Modified: / ET.tex Log: * add hydro equations File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +83 -3 =================================================================== --- ET.tex 2011-08-01 14:55:33 UTC (rev 95) +++ ET.tex 2011-08-01 15:23:53 UTC (rev 96) @@ -966,9 +966,9 @@ one may also apply a uniform velocity to the neutron star, though this does not affect the ODE solution nor the resulting density profile. -\subsection{Spacetime Curvature and Hydrodynamics Evolution} +\subsection{Spacetime Curvature Evolution} \label{sec:evol} -\todo{Christian in charge} +\todo{Josh and Christian in charge} In the following, we assume that the reader is familiar with the basics of numerical relativity and GR hydrodynamics. Detailed @@ -1266,11 +1266,91 @@ gauge conditions used in \codename{McLachlan}. -\subsection{Hydrodynamics: \codename{GRHydro}}\pages{Christian} +\subsection{Hydrodynamics: \codename{GRHydro}}\pages{Christian and Josh} \label{sec:GRHydro} +{\color{red} This text is copied from Reisswig et al. It needs to be expanded a bit and we probably want to talk about the numerical methods a bit more.} +The equations of ideal GR hydrodynamics evolved by \codename{GRHydro} are +derived from the local GR conservation laws of mass and +energy-momentum, +\begin{equation} + \nabla_{\!\mu} J^\mu = 0, \qquad \nabla_{\!\mu} T^{\mu \nu} = 0\,\,, + \label{eq:equations_of_motion_gr} +\end{equation} +where $ \nabla_{\!\mu} $ denotes the covariant derivative with respect +to the 4-metric. $ J^{\,\mu} = \rho u^{\,\mu} $ is the mass current +with the 4-velocity $ u^{\,\mu} $ and the rest-mass density $\rho$. $ +T^{\mu \nu} = \rho h u^{\,\mu} u^{\,\nu} + P g^{\,\mu \nu} $ is the +stress-energy tensor. The quantity $ h = 1 + \epsilon + P / \rho $ is +the specific enthalpy, $P$ is the fluid pressure and $\epsilon$ is the +specific internal energy. +We choose a definition of the 3-velocity that corresponds to the +velocity seen by an Eulerian observer at rest in the current spatial +3-hypersurface \cite{york:83}, +\begin{equation} +v^i = \frac{u^i}{W} + \frac{\beta^i}{\alpha}\,\,, +\label{eq:vel} +\end{equation} +where $W = (1-v^i v_i)^{-1/2}$ is the Lorentz factor. In terms of +the 3-velocity, the contravariant 4-velocity is then given by +\begin{equation} +u^0 = \frac{W}{\alpha}\,,\qquad +u^i = W \left( v^i - \frac{\beta^i}{\alpha}\right)\,\,, +\end{equation} +and the covariant 4-velocity is +\begin{equation} +u_0 = W(v^i \beta_i - \alpha)\,,\qquad +u_i = W v_i\,\,. +\end{equation} + +The {\tt GRHydro} scheme is written in a first-order hyperbolic +flux-conservative evolution system for the conserved variables +$\hat{D}$, $\hat{S}^i$, and $\hat{\tau}$ in terms of the primitive +variables $\rho, \epsilon, v^i$, +\begin{eqnarray} + \hat{D} &=& \sqrt{\gamma} \rho W,\nonumber\\ + \hat{S}^i &=& \sqrt{\gamma} \rho h W^{\,2} v^i,\nonumber\\ + \hat{\tau} &=& \sqrt{\gamma} \left(\rho h W^{\,2} - P\right) - D\,, +\end{eqnarray} +where $ \gamma $ is the determinant of $\gamma_{ij} $. +The evolution system then becomes +\begin{equation} + \frac{\partial \mathbf{U}}{\partial t} + + \frac{\partial \mathbf{F}^{\,i}}{\partial x^{\,i}} = + \mathbf{S}\,\,, + \label{eq:conservation_equations_gr} +\end{equation} +with +\begin{eqnarray} + \mathbf{U} & = & [\hat{D}, \hat{S}_j, \hat{\tau}], \nonumber\\ + \mathbf{F}^{\,i} & = & \alpha + \left[ \hat{D} \tilde{v}^{\,i}, \hat{S}_j \tilde{v}^{\,i} + \delta^{\,i}_j P, + \hat{\tau} \tilde{v}^{\,i} + P v^{\,i} \right]\!, \nonumber \\ + \mathbf{S} & = & \alpha + \bigg[ 0, T^{\mu \nu} \left( \frac{\partial g_{\nu j}}{\partial x^{\,\mu}} - + \Gamma^{\,\lambda}_{\mu \nu} g_{\lambda j} \right), \nonumber\\ + & &\qquad\alpha \left( T^{\mu 0} + \frac{\partial \ln \alpha}{\partial x^{\,\mu}} - + T^{\mu \nu} \Gamma^{\,0}_{\mu \nu} \right) \bigg]\,. +\end{eqnarray}% +% +Here, $ \tilde{v}^{\,i} = v^{\,i} - \beta^i / \alpha $ and $ +\Gamma^{\,\lambda}_{\mu \nu} $ are the 4-Christoffel symbols. The +above equations are solved in semi-discrete fashion. The spatial +discretization is performed by means of a high-resolution +shock-capturing (HRSC) scheme employing a second-order accurate +finite-volume discretization. We make use of the Marquina flux formula +for the local Riemann problems and piecewise-parabolic cell interface +reconstruction (PPM\@). For a review of such methods in the GR context, +see~\cite{font:08}. The time integration and coupling with curvature +are carried out with the Method of +Lines~\cite{Hyman-1976-Courant-MOL-report}. + + + + \subsection{Equations of State}\pages{1 Christian} \label{sec:eoss}

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 95)
by knarf＠cct.lsu.edu 01 Aug '11

01 Aug '11

User: knarf Date: 2011/08/01 09:55 AM Added: / TODO Modified: / ET.tex Log: a temporary TODO file File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +10 -6 =================================================================== --- ET.tex 2011-08-01 13:21:13 UTC (rev 94) +++ ET.tex 2011-08-01 14:55:33 UTC (rev 95) @@ -23,6 +23,8 @@ \graphicspath{{figures/}} +\setcounter{secnumdepth}{5} + \def\grb#1{gamma-ray burst#1 (GRB#1)\gdef\grb{GRB}} \def\gw#1{gravitational wave#1 (GW#1)\gdef\gw{GW}} \def\bh#1{black hole#1 (BH#1)\gdef\bh{BH}} @@ -579,7 +581,7 @@ and conventions (see section~\ref{sec:base_modules}). Others provide initial data (see section~\ref{sec:initial_data}). These initial data have to be evolved, using different evolution methods, described in -sections~\ref{sec:Kevol} and~\ref{sec:GRHydro}. +section~\ref{sec:evol}. Simulations including matter require a description of the matter properties, encoded in equations of state (see section~\ref{sec:eoss}). @@ -965,7 +967,7 @@ the ODE solution nor the resulting density profile. \subsection{Spacetime Curvature and Hydrodynamics Evolution} -\label{sec:Kevol} +\label{sec:evol} \todo{Christian in charge} In the following, we assume that the reader is familiar with the @@ -1002,7 +1004,9 @@ the relativistic specific enthalpy with $\epsilon$ and $P$ being the specific internal energy and the pressure, respectively. -\subsubsection{Spacetime Curvature Evolution} The Einstein Toolkit +\subsubsection{Spacetime Curvature Evolution} +\label{sec:Kevol} +The Einstein Toolkit curvature evolution code \codename{McLachlan}~\cite{brown:09,reisswig:11ccwave} is auto-generated from tensor equations via \codename{Kranc} (Sec.~\ref{sec:kranc}). It implements the Einstein equations in a @@ -1169,7 +1173,7 @@ -\subsubsection{Initial Conditions} +\paragraph{Initial Conditions} Initial conditions from the ADM variables $g_{ij}$, $K_{ij}$, lapse $\alpha$, and shift $\beta^i$, as provided by the initial data @@ -1193,7 +1197,7 @@ then defined via the points in the interior and the previously calculated layers. -\subsubsection{Boundary Conditions} +\paragraph{Boundary Conditions} \label{sec:curv_boundaries} During time evolution, a Sommerfeld-type radiative boundary condition @@ -1262,7 +1266,7 @@ gauge conditions used in \codename{McLachlan}. -\subsection{Hydrodynamics: \codename{GRHydro}} +\subsection{Hydrodynamics: \codename{GRHydro}}\pages{Christian} \label{sec:GRHydro} File [added]: TODO Delta lines: +9 -0 =================================================================== --- TODO (rev 0) +++ TODO 2011-08-01 14:55:33 UTC (rev 95) @@ -0,0 +1,9 @@ +someone (1) : references! + +Ian Hinder : Expand section on Kranc, a bit +Christian Ott: Curvature evolution looks good, but what about GRHydro? + EOS? +Peter : Tools not ready (puncture and star tracker, but into analysis) +Roland : Merge AMR sections (4.2 and 5.8.3 currently) +Peter, Frsank, Bruno, Christian: Examples! +Frank : Future Work

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 94)
by knarf＠cct.lsu.edu 01 Aug '11

01 Aug '11

User: knarf Date: 2011/08/01 08:21 AM Modified: / ET.tex Log: improvements/corrections/comments froom one pass of reading File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +102 -68 =================================================================== --- ET.tex 2011-06-27 15:54:01 UTC (rev 93) +++ ET.tex 2011-08-01 13:21:13 UTC (rev 94) @@ -94,7 +94,7 @@ % to be used \begin{abstract} -\todo{ADDME} +\todo{ADDME, Frank} \end{abstract} \maketitle @@ -102,10 +102,10 @@ % We will remove this at the end, but we leave it in for ourselfes now \tableofcontents -\section{Introduction\pages{1 Frank}} +\section{Introduction\pagesdone{Frank}} Scientific progress in the field of numerical relativity has always -been closely tied with the availability and ease-of-use of enabling +been closely tied to the availability and ease-of-use of enabling software and computational infrastructure. This document describes the Einstein Toolkit, which aims at providing such an infrastructure, developed openly and available freely, and is directly supported by @@ -141,8 +141,8 @@ evolve binary BHs have proven to be equally applicable to merging BH-NS and NS-NS binaries, allowing for the first full GR simulations of these systems (e.g.,~\cite{Shibata:2006bs,Shibata:2006ks,Loeffler06a,Shibata:2007zm, -Etienne:2007jg,Baiotti:2008ra,Duez:2008rb}), and spured a lot of activity -also in this field~\todo{cite}. +Etienne:2007jg,Baiotti:2008ra,Duez:2008rb}), and spurring a lot of activity +also in this field~\todo{cite more}. General relativistic magneto-hydrodynamics (GRMHD) on fixed background spacetimes has been carried out in multi-dimensional @@ -187,7 +187,7 @@ computer science directly to problems in numerical relativity. This success spawned usage of the Cactus computational toolkit in other -areas, such as hurricane forecast models. At the same time, the growing +areas, such as hurricane forecast models~\todo{cite}. At the same time, the growing number of results in numerical relativity increased the need for commonly available utilities such as comparison and analysis tools, typically problem-specific to astrophysical problems. Including them within the @@ -196,7 +196,7 @@ presently do make use of the Cactus toolkit, this is not an requirement at all, and other contributions are welcome and have been accepted. -\section{Requirements\pages{2 Frank}} +\section{Requirements\pagesdone{Frank}} \subsection{Scientific} @@ -302,7 +302,7 @@ a framework developed by computer scientists and now used by researchers is many other fields. -\section{Design and Strategy\pages{0.5 Frank}} +\section{Design and Strategy\pagesdone{0.5 Frank}} The mechanisms for the development and support of the Einstein Toolkit are designed to be open, transparent and community-driven. The complete source code, @@ -312,8 +312,8 @@ supported by the Einstein Toolkit, the toolkit web pages and documentation. An open wiki for documentation ({\tt docs.einsteintoollkit.org}) has been established where the community -can contribute either anonymously or through personal authentication. All -discussion about the toolkit takes place on an open mail list +can contribute either anonymously or through personal authentication. Almost +all discussions about the toolkit take place on an open mail list ({\tt users(a)einsteintoolkit.org}). The regular weekly meetings for the Einstein Toolkit are open and the community is invited to participate. Meeting minutes are recorded and publicly available as well. @@ -323,8 +323,8 @@ The community heavily uses an issue tracking system ({\tt trac.einsteintoolkit.org}), with submissions also open to everyone. -Despite this open design, some actions have to be restricted to a small -group of maintainers. This is true for e.g.\ administrative tasks like the +Despite this open design, some actions naturaly have to be restricted to a small +group of maintainers. This is true for, e.g., administrative tasks like the setup and maintenance of the services itself, or to avoid large amounts of spam. However, one of the most important tasks of an Einstein Toolkit Maintainer is to review and apply patches sent by users in order to ensure @@ -334,10 +334,20 @@ despite not being technically enforced, works well in practice, and is at the same time promoting active development. -\section{Core Technologies\pages{0.5 Frank}} +\section{Core Technologies\pagesdone{Frank}} -\subsection{Cactus Framework\pages{1 Frank}} +The Einstein Toolkit consists of a lot of components which, combined by the +user, are utilized together to perform a full simulation. While all of these +components have important tasks, a few stand out. Of these, the following four +are described in more detail below: the Cactus framework, providing the glue +between a lot of the other components, the handling of adaptive mesh refinement +without which most results could not have been obtained in reasonable time, +the simulation factory, because it simplifies the necessary supercomputer usage, +and Kranc, which can generate code in a computer language from a high-level +description in Mathematica. +\subsection{Cactus Framework\pagesdone{1 Frank}} + The \textbf{Cactus Framework}~\cite{CS_cactus_web,CS_Goodale02a,CS_cactususersguide} is an open source, modular, portable programming environment for @@ -374,7 +384,7 @@ relativity, as part of the \texttt{CactusEinstein} arrangement. Over the last few years however, the relevance of many of the modules has declined, and more and more of the basic infrastructure for numerical relativity -has been provided by open modules provided and distributed by research +has been provided by open modules distributed by research groups in the community. The Einstein Toolkit now collects the widely used parts of CactusEinstein, combined with contributions from the community. @@ -523,7 +533,7 @@ The above features make running simulations on supercomputers much safer and simpler. -\subsection{Kranc\pages{1 Ian}} +\subsection{Kranc\pages{1 Ian: expand - we could write so much more here}} \label{sec:kranc} Kranc\cite{Husa:2004ip,kranc04,krancweb} is a Mathematica application which converts a high-level @@ -561,9 +571,24 @@ as well as the wave extraction thorn WeylScal4, are both generated using Kranc, and hence support all the above features. -\section{Components\pages{0.5 Frank}} +\section{Components\pagesdone{Frank}} +The Einstein Toolkit uses the Cactus framework as underlying infrastructure, +which promotes a very modular design. A simulation within Cactus could just +use one module, but in practice simulations are often composed from over +one hundered components. Some of these modules provide common definitions +and conventions (see section~\ref{sec:base_modules}). Others provide +initial data (see section~\ref{sec:initial_data}). These initial data +have to be evolved, using different evolution methods, described in +sections~\ref{sec:Kevol} and~\ref{sec:GRHydro}. +Simulations including +matter require a description of the matter properties, encoded in equations +of state (see section~\ref{sec:eoss}). +Finally, other quantities besides the ones used for evolution are often +interesting for a detailed analysis of the results of a simulation. +Modules providing commonly used analysis methods are described in +section~\ref{sec:analysis}. -\subsection{Base Modules\pages{4 Frank}} +\subsection{Base Modules\pagesdone{Frank}} \label{sec:base_modules} Modular designs have proven to be essential for distributed development of complex software systems, and require the use of well defined interfaces. @@ -571,7 +596,8 @@ the Cactus infrastructure. One example of this is using one module from within another, e.g., by calling a function within another thorn independent of programming language used for both the calling and the -called function. +called function. Technical challenges like this can be and are +provided by the underlying framework, in this case by Cactus. However, certain other standards are very hard or impossible to enforce on a technical level. Examples for these are the exact @@ -579,7 +605,8 @@ technical level the variable names used for the physical quantities. In addition, even distinct simulation codes typically use very similar scheduling schemes. Conventions on the level of the scheduler can help -coordinating the order different modules are called. +coordinating the order in which functions in which different modules +are called. The Einstein Toolkit provides modules with the sole purpose to declare commonly used variables, and to define their meaning and units. @@ -598,58 +625,67 @@ the three-metric $\gamma_ij$, the extrinsic curvature $K_ij$, the lapse function $\alpha$ and shift function $\beta^i$, -both together with their first time derivatives. +the latter two together with their first time derivatives. This base module also defines common parameters to manage interaction -between different modules, like which type of initial data should -be setup or which evolution method should be used. +between different modules. Examples are the type of requested initial data +or the used evolution method. The variables provided by {\tt ADMBase} are: \begin{itemize} \item - The 3-metric tensor, $g_{ij}$ + The 3-metric tensor, $g_{ij}$: {\tt gxx}, {\tt gxy}, {\tt gxz},{\tt gyy}, {\tt gyz},{\tt gzz} - \item The extrinsic curvature tensor, $K_{ij}$ + \item The extrinsic curvature tensor, $K_{ij}$: {\tt kxx}, {\tt kxy}, {\tt kxz},{\tt kyy},{\tt kyz},{\tt kzz} - \item The lapse function, $\alpha$ + \item The lapse function, $\alpha$: {\tt alp} - \item The shift vector $\beta^i$ + \item The shift vector $\beta^i$: {\tt betax}, {\tt betay},{\tt betaz} \end{itemize} -The type of chosen initial data for a simulation is specified by the {\tt -initial\_data} (3-metric and extrinsic curvature), -{\tt initial\_lapse}, {\tt initial\_shift} parameters, and -parameters for their first time derivatives {\tt initial\_dtlapse} and +The type of chosen initial data for a simulation is specified by the +parameters{\tt initial\_data} (3-metric and extrinsic curvature), +{\tt initial\_lapse}, {\tt initial\_shift}, and by +parameters for their first time derivatives, {\tt initial\_dtlapse} and {\tt initial\_dtshift} respectively. By default, {\tt ADMBase} initialises the 3-metric and extrinsic curvature to Minkowski and the lapse to one. Initial data thorns override these defaults by extending the parameters. Analogous to specifying initial data, evolution methods are chosen by -the {\tt evolution\_method} (3-metric and extrinsic curvature), +the parameters {\tt evolution\_method} (3-metric and extrinsic curvature), {\tt lapse\_evolution\_method}, {\tt shift\_evolution\_method}, -{\tt dtlapse\_evolution\_method} and {\tt dtshift\_evolution\_method} -parameters. {\tt ADMBase} does not evolve the +{\tt dtlapse\_evolution\_method} and {\tt dtshift\_evolution\_method}. +{\tt ADMBase} does not evolve the 3-metric or extrinsic curvature, and holds the lapse and shift static. -Evolution thorns typically extend the ranges of these parameters and +Evolution thorns extend the ranges of these parameters and contain the evolution code. +The variables defined in ADMBase are typically not used for the actual +evolution of the curvature. ADMBase does not restrict that coice. However, +it is expected that every evolution module converts its internal representation +to the form defined in ADMBase after each evolution step. This procedure +enables modules performing analysis on the spacetime variables to use +the ADMBase variables without direct dependency on any of the existing +curvature evolution methods. + \subsubsection{HydroBase} -Similar to \codename{ADMBase}, the module \codename{HydroBase} defines the common -basis for interactions between relativistic hydrodynamics modules. -HydroBase extends the CactusEinstein framework to include an interface for magnetohydrodynamics to -work within. HydroBase's main function is to store the primitive variables, common among -hydrodynamic simulations, commonly needed parameters, and schedule groups for the main -functions of a hydrodynamics code. -HydroBase only stores variables which -are common to most if not all hydrodynamics codes solving the Euler -equations, the so called primitive variables. These are also the variables which are needed -to couple to a spacetime solver and which are usually needed by analysis thorns. The usage of -a common set of variables by different hydrodynamics codes creates the possibility to share -parts of the code, e.g.\ initial data solvers or analysis routines. +Similar to \codename{ADMBase}, the module \codename{HydroBase} defines common +basis for interactions between modules of a given evolution problem, in this +case relativistic hydrodynamics. HydroBase extends the Einstein Toolkit to +include an interface for magnetohydrodynamics to work within. HydroBase's main +function is to store variables which are common to most if not all +hydrodynamics codes solving the Euler equations, the so called primitive +variables. These are also the variables which are needed to couple to a +spacetime solver and which are usually needed by analysis thorns. Like for +ADMBase, the usage of a common set of variables by different hydrodynamics +codes creates the possibility to share parts of the code, e.g.\ initial data +solvers or analysis routines. +HydroBase also defines commonly needed parameters, and schedule +groups for the main functions of a hydrodynamics code. -It is using the conventions of the Valencia +HydroBase is using the conventions of the Valencia formulation~\cite{Marti:1991wi,Banyuls:1997zz,Ibanez:2001:godunov}. In particular, HydroBase defines the primitive variables (see~\cite{livrevgrfd} for details): @@ -699,7 +735,7 @@ variables, and basic atmosphere handling can be implemented in different thorns while allowing a central access point for analysis thorns. -\subsection{Initial Data\pages{4 Josh/Bruno}} +\subsection{Initial Data\pagesdone{Josh/Bruno}} \label{sec:initial_data} The Einstein Toolkit contains many modules used to generate initial data for @@ -928,10 +964,8 @@ one may also apply a uniform velocity to the neutron star, though this does not affect the ODE solution nor the resulting density profile. - -\subsection{Equations of State}\pages{1 Christian} - \subsection{Spacetime Curvature and Hydrodynamics Evolution} +\label{sec:Kevol} \todo{Christian in charge} In the following, we assume that the reader is familiar with the @@ -1160,6 +1194,7 @@ calculated layers. \subsubsection{Boundary Conditions} +\label{sec:curv_boundaries} During time evolution, a Sommerfeld-type radiative boundary condition is applied to all components of the evolved BSSN variables as @@ -1227,16 +1262,16 @@ gauge conditions used in \codename{McLachlan}. +\subsection{Hydrodynamics: \codename{GRHydro}} +\label{sec:GRHydro} +\subsection{Equations of State}\pages{1 Christian} +\label{sec:eoss} -\subsubsection{Hydrodynamics: \codename{GRHydro}} -\label{sec:GRHydro} - - - -\subsection{Analysis\pages{4 Tanja}} +\subsection{Analysis\pagesdone{Tanja}} +\label{sec:analysis} It is often beneficial and sometimes necessary to evaluate analysis quantities during the simulation rather than post-processing variable output. Beyond extracting physics, these quantities are often used as measures of how @@ -1661,7 +1696,7 @@ ghost points off the plane (see Figure~\ref{fig:cartoon-plane}). \begin{figure}[htbp] \begin{center} - \includegraphics[width=0.25\textwidth]{cartoon_plane} + \includegraphics[width=0.2\textwidth]{cartoon_plane} \end{center} \caption{Grid layout of a simulation using \codename{Cartoon2D}. The $z$-axis is the axis of rotational symmetry. Image courtesy of @@ -1716,15 +1751,13 @@ 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. +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}. -\comment{RH: Christian already describes NewRad's boundary conditions in -his section (these should be used for extrapolation and radiative -boundary conditions I think). Should they eventually be moved here (once -the paper is almost ready)?} \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 @@ -1813,6 +1846,7 @@ \section{Examples\pages{0.5 Frank}} +\todo{Will be written once we know which examples we have} \subsection{Spinning BH\pages{2 Peter}} @@ -1825,7 +1859,7 @@ \subsection{Collapse\pages{2 Christian}} Show TOV collapse and BH formation -\subsection{Cosmology} +\subsection{Cosmology\pagesdone{1}} The Einstein Toolkit is not only designed to evolve compact-object spacetimes, but it is also capable of solving the initial-value problem for spacetimes with radically different topology and global @@ -1875,7 +1909,7 @@ \section{Future Work\pages{1 Frank}} -This paper illustrated the current state of the ``Einstein Toolkit'', +In this paper we illustrated the current state of the ``Einstein Toolkit'', a collection of freely available and easy to use computational codes for numerical relativity. However, there is room for improvement on both the underlying infrastructure and the included physics. @@ -1884,9 +1918,9 @@ radiation, in particular neutrinos, but possibly even some approximation of emmission of electro-magnetic waves. Radiation transport is, even compared to the full GRMHD problem, computationally very expensive, especially in -three dimensions. \todo{mention PetaCactus} +three dimensions. \todo{Erik: mention PetaCactus} -\todo{mention advanced wave extraction} +\todo{CCE people: mention advanced wave extraction} Another important goal is to increase the scalability of the Carpet AMR infrastructure. It has been shown that good scaling is limited to less than

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Commits August 2011