Commits November 2011

commits@lists.einsteintoolkit.org

13 participants
183 discussions

[svn:einsteintoolkit] EOS_Omni/trunk/ (Rev. 54)
by knarf＠cct.lsu.edu 13 Nov '11

13 Nov '11

User: knarf Date: 2011/11/13 09:50 AM Added: /trunk/src/nuc_eos/ readtable.c Removed: /trunk/src/nuc_eos/ readtable.F90 Modified: /trunk/ param.ccl, schedule.ccl /trunk/src/ EOS_Omni_Startup.F90 /trunk/src/nuc_eos/ eosmodule.F90, make.code.defn Log: Let EOS_Omni read HDF5 EOSs using the C-API, since building the fortran interface is usually disabled, and conflicts with the parallel API as well. File Changes: Directory: /trunk/src/nuc_eos/ ============================== File [modified]: eosmodule.F90 Delta lines: +46 -0 =================================================================== --- trunk/src/nuc_eos/eosmodule.F90 2011-10-25 18:45:07 UTC (rev 53) +++ trunk/src/nuc_eos/eosmodule.F90 2011-11-13 15:50:01 UTC (rev 54) @@ -1,3 +1,8 @@ +#include "cctk.h" +#include "cctk_Parameters.h" +#include "cctk_Arguments.h" +#include "cctk_Functions.h" + module eosmodule implicit none @@ -58,3 +63,44 @@ end module eosmodule + +! This function is called from within readtable.c +! It copies the values of the arrays given as parameters into arrays +! of the eos module, until I can find out how I can use those arrays +! directly. +subroutine allocate_eosmodule(nrho_, ntemp_, nye_, alltables_, logrho_, logtemp_, ye_, energy_shift_) + use eosmodule + CCTK_INT :: nrho_, ntemp_, nye_ + CCTK_REAL :: alltables_(nrho_, ntemp_, nye_, 19) + CCTK_REAL :: logrho_(nrho_) + CCTK_REAL :: logtemp_(ntemp_) + CCTK_REAL :: ye_(nye_) + CCTK_REAL :: energy_shift_ + + nrho = nrho_ + ntemp = ntemp_ + nye = nye_ + + allocate(alltables(nrho,ntemp,nye,nvars)) + allocate(logrho(nrho)) + allocate(logtemp(ntemp)) + allocate(ye(nye)) + alltables = alltables_ + logrho = logrho_ + logtemp = logtemp_ + ye = ye_ + + energy_shift = energy_shift_ + + ! set min-max values: + eos_rhomin = 10.0d0**logrho(1) + eos_rhomax = 10.0d0**logrho(nrho) + + eos_yemin = ye(1) + eos_yemax = ye(nye) + + eos_tempmin = 10.0d0**logtemp(1) + eos_tempmax = 10.0d0**logtemp(ntemp) + +end subroutine allocate_eosmodule + File [modified]: make.code.defn Delta lines: +1 -1 =================================================================== --- trunk/src/nuc_eos/make.code.defn 2011-10-25 18:45:07 UTC (rev 53) +++ trunk/src/nuc_eos/make.code.defn 2011-11-13 15:50:01 UTC (rev 54) @@ -1,5 +1,5 @@ SRCS = eosmodule.F90 nuc_eos.F90 bisection.F90 \ - findtemp.F90 findrho.F90 linterp_many.F90 readtable.F90 \ + findtemp.F90 findrho.F90 linterp_many.F90 readtable.c \ linterp.F SUBDIRS = File [removed]: readtable.F90 Delta lines: +0 -264 =================================================================== --- trunk/src/nuc_eos/readtable.F90 2011-10-25 18:45:07 UTC (rev 53) +++ trunk/src/nuc_eos/readtable.F90 2011-11-13 15:50:01 UTC (rev 54) @@ -1,264 +0,0 @@ -#include "cctk.h" -#include "cctk_Parameters.h" - - -subroutine nuc_eos_readtable(eos_filename) -! This routine reads the table and initializes -! all variables in the module. - - use eosmodule - use hdf5 - - implicit none - - DECLARE_CCTK_PARAMETERS - - character(*) eos_filename - - character(len=100) message - -! HDF5 vars - integer(HID_T) file_id,dset_id,dspace_id - integer(HSIZE_T) dims1(1), dims3(3) - integer error,rank,accerr - integer i,j,k - - real*8 amu_cgs_andi - real*8 buffer1,buffer2,buffer3,buffer4 - accerr=0 - -! write(*,*) "Reading Nuclear EOS Table" - - call h5open_f(error) - - call h5fopen_f (trim(adjustl(eos_filename)), H5F_ACC_RDONLY_F, file_id, error) - -! write(6,*) trim(adjustl(eos_filename)) - -! read scalars - dims1(1)=1 - call h5dopen_f(file_id, "pointsrho", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_INTEGER, nrho, dims1, error) - call h5dclose_f(dset_id,error) - - if(error.ne.0) then - call CCTK_WARN (0, "Could not read EOS table file") - endif - - dims1(1)=1 - call h5dopen_f(file_id, "pointstemp", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_INTEGER, ntemp, dims1, error) - call h5dclose_f(dset_id,error) - - if(error.ne.0) then - call CCTK_WARN (0, "Could not read EOS table file") - endif - - dims1(1)=1 - call h5dopen_f(file_id, "pointsye", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_INTEGER, nye, dims1, error) - call h5dclose_f(dset_id,error) - - if(error.ne.0) then - call CCTK_WARN (0, "Could not read EOS table file") - endif - -! write(message,"(a25,1P3i5)") "We have nrho ntemp nye: ", nrho,ntemp,nye -! write(*,*) message - - allocate(alltables(nrho,ntemp,nye,nvars)) - - ! index variable mapping: - ! 1 -> logpress - ! 2 -> logenergy - ! 3 -> entropy - ! 4 -> munu - ! 5 -> cs2 - ! 6 -> dedT - ! 7 -> dpdrhoe - ! 8 -> dpderho - ! 9 -> muhat - ! 10 -> mu_e - ! 11 -> mu_p - ! 12 -> mu_n - ! 13 -> xa - ! 14 -> xh - ! 15 -> xn - ! 16 -> xp - ! 17 -> abar - ! 18 -> zbar - - - dims3(1)=nrho - dims3(2)=ntemp - dims3(3)=nye - call h5dopen_f(file_id, "logpress", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,1), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - call h5dopen_f(file_id, "logenergy", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,2), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - call h5dopen_f(file_id, "entropy", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,3), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - call h5dopen_f(file_id, "munu", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,4), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - call h5dopen_f(file_id, "cs2", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,5), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - call h5dopen_f(file_id, "dedt", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,6), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - call h5dopen_f(file_id, "dpdrhoe", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,7), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - call h5dopen_f(file_id, "dpderho", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,8), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - -! chemical potentials - call h5dopen_f(file_id, "muhat", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,9), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - call h5dopen_f(file_id, "mu_e", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,10), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - call h5dopen_f(file_id, "mu_p", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,11), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - call h5dopen_f(file_id, "mu_n", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,12), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - -! compositions - call h5dopen_f(file_id, "Xa", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,13), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - call h5dopen_f(file_id, "Xh", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,14), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - call h5dopen_f(file_id, "Xn", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,15), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - call h5dopen_f(file_id, "Xp", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,16), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - -! average nucleus - call h5dopen_f(file_id, "Abar", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,17), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - call h5dopen_f(file_id, "Zbar", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,18), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - -! Gamma - call h5dopen_f(file_id, "gamma", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, alltables(:,:,:,19), dims3, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - allocate(logrho(nrho)) - dims1(1)=nrho - call h5dopen_f(file_id, "logrho", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, logrho, dims1, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - allocate(logtemp(ntemp)) - dims1(1)=ntemp - call h5dopen_f(file_id, "logtemp", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, logtemp, dims1, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - allocate(ye(nye)) - dims1(1)=nye - call h5dopen_f(file_id, "ye", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, ye, dims1, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - - call h5dopen_f(file_id, "energy_shift", dset_id, error) - call h5dread_f(dset_id, H5T_NATIVE_DOUBLE, energy_shift, dims1, error) - call h5dclose_f(dset_id,error) - accerr=accerr+error - - if(accerr.ne.0) then - call CCTK_WARN (0, "Problem reading EOS table file") - endif - - call h5fclose_f (file_id,error) - - if(do_energy_shift.ne.1) then - energy_shift = 0.0d0 - endif - -! not a good idea to call this function as it will screw recovery -! call h5close_f (error) - - ! set min-max values: - - eos_rhomin = 10.0d0**logrho(1) - eos_rhomax = 10.0d0**logrho(nrho) - - eos_yemin = ye(1) - eos_yemax = ye(nye) - - eos_tempmin = 10.0d0**logtemp(1) - eos_tempmax = 10.0d0**logtemp(ntemp) - -! write(6,*) "Done reading eos tables" - -#if 0 -! if using the actual garching table; -! keep this around for compatiblity and to -! reproduce 2006 results using the Garching Shen EOS table. - amu_cgs_andi = 1.66d-24 - do i=1,nrho - do j=1,ntemp - do k=1,nye - buffer1 = 10.0d0**alltables(i,j,k,2) - buffer1 = buffer1*amu_cgs_andi/mev_to_erg - buffer2 = (buffer1 + 939.5731d0 - 10.8d0 - amu_mev) - buffer3 = buffer2 - ye(k)*0.511d0 - buffer4 = buffer3/amu_cgs * mev_to_erg - alltables(i,j,k,2) = log10(buffer4) - enddo - enddo - enddo -#endif - - - -end subroutine nuc_eos_readtable - - File [added]: readtable.c Delta lines: +139 -0 =================================================================== --- trunk/src/nuc_eos/readtable.c (rev 0) +++ trunk/src/nuc_eos/readtable.c 2011-11-13 15:50:01 UTC (rev 54) @@ -0,0 +1,139 @@ +#include <stdlib.h> + +#include "hdf5.h" + +#include "cctk.h" +#include "cctk_Parameters.h" +#include "cctk_Arguments.h" +#include "cctk_Functions.h" + +// Interface of function for fortran module eostable +void CCTK_FNAME(allocate_eosmodule) + (CCTK_INT* , CCTK_INT* , CCTK_INT*, CCTK_REAL*, + CCTK_REAL*, CCTK_REAL*, CCTK_REAL*, CCTK_REAL*); + +// Catch HDF5 errors +#define HDF5_ERROR(fn_call) \ + do { \ + int _error_code = fn_call; \ + if (_error_code < 0) \ + CCTK_VWarn (CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, \ + "HDF5 call '%s' returned error code %d", \ + #fn_call, _error_code); \ + } while (0) + +int file_is_readable(const char* filename); +int file_is_readable(const char* filename) +{ + FILE* fp = NULL; + fp = fopen(filename, "r"); + if(fp != NULL) + { + fclose(fp); + return 1; + } + return 0; +} + +// Cactus calls this function. It reads in the table and calls a fortran +// function to setup values for the fortran eos module +void EOS_OMNI_ReadTable(CCTK_ARGUMENTS); +void EOS_OMNI_ReadTable(CCTK_ARGUMENTS) +{ + DECLARE_CCTK_PARAMETERS + DECLARE_CCTK_ARGUMENTS + + hid_t file; + if (!file_is_readable(nuceos_table_name)) + CCTK_VWarn(CCTK_WARN_ABORT, __LINE__, __FILE__, CCTK_THORNSTRING, + "Could not read nuceos_table_name'%s'", + nuceos_table_name); + HDF5_ERROR(file = H5Fopen(nuceos_table_name, H5F_ACC_RDONLY, H5P_DEFAULT)); + +// Use these two defines to easily read in a lot of variables in the same way +// The first reads in one variable of a given type completely +#define READ_EOS_HDF5(NAME,VAR,TYPE,MEM) \ + do { \ + hid_t dataset; \ + HDF5_ERROR(dataset = H5Dopen(file, NAME, H5P_DEFAULT)); \ + HDF5_ERROR(H5Dread(dataset, TYPE, MEM, H5S_ALL, H5P_DEFAULT, VAR)); \ + HDF5_ERROR(H5Dclose(dataset)); \ + } while (0) +// The second reads a given variable into a hyperslab of the alltables array +#define READ_EOSTABLE_HDF5(NAME,OFF) \ + do { \ + hsize_t offset[2] = {OFF,0}; \ + H5Sselect_hyperslab(mem3, H5S_SELECT_SET, offset, NULL, var3, NULL); \ + READ_EOS_HDF5(NAME,alltables,H5T_NATIVE_DOUBLE,mem3); \ + } while (0) + + // Read size of tables + CCTK_INT nrho, ntemp, nye; + + READ_EOS_HDF5("pointsrho", &nrho, H5T_NATIVE_INT, H5S_ALL); + READ_EOS_HDF5("pointstemp", &ntemp, H5T_NATIVE_INT, H5S_ALL); + READ_EOS_HDF5("pointsye", &nye, H5T_NATIVE_INT, H5S_ALL); + + // Allocate memory for tables + CCTK_REAL *alltables, *logrho, *logtemp, *ye, energy_shift; + + if (!(alltables = (CCTK_REAL*)malloc(nrho * ntemp * nye * 19 * sizeof(CCTK_REAL)))) + CCTK_WARN(CCTK_WARN_ABORT, "Cannot allocate memory for EOS table\n"); + if (!(logrho = (CCTK_REAL*)malloc(nrho * sizeof(CCTK_REAL)))) + CCTK_WARN(CCTK_WARN_ABORT, "Cannot allocate memory for EOS table\n"); + if (!(logtemp = (CCTK_REAL*)malloc(ntemp * sizeof(CCTK_REAL)))) + CCTK_WARN(CCTK_WARN_ABORT, "Cannot allocate memory for EOS table\n"); + if (!(ye = (CCTK_REAL*)malloc(nye * sizeof(CCTK_REAL)))) + CCTK_WARN(CCTK_WARN_ABORT, "Cannot allocate memory for EOS table\n"); + + // Prepare HDF5 to read hyperslabs into alltables + hsize_t table_dims[2] = {19, nrho * ntemp * nye}; + hsize_t var3[2] = { 1, nrho * ntemp * nye}; + hid_t mem3 = H5Screate_simple(2, table_dims, NULL); + + // Read alltables + READ_EOSTABLE_HDF5("logpress", 0); + READ_EOSTABLE_HDF5("logenergy", 1); + READ_EOSTABLE_HDF5("entropy", 2); + READ_EOSTABLE_HDF5("munu", 3); + READ_EOSTABLE_HDF5("cs2", 4); + READ_EOSTABLE_HDF5("dedt", 5); + READ_EOSTABLE_HDF5("dpdrhoe", 6); + READ_EOSTABLE_HDF5("dpderho", 7); + // chemical potentials + READ_EOSTABLE_HDF5("muhat", 8); + READ_EOSTABLE_HDF5("mu_e", 9); + READ_EOSTABLE_HDF5("mu_p", 10); + READ_EOSTABLE_HDF5("mu_n", 11); + // compositions + READ_EOSTABLE_HDF5("Xa", 12); + READ_EOSTABLE_HDF5("Xh", 13); + READ_EOSTABLE_HDF5("Xn", 14); + READ_EOSTABLE_HDF5("Xp", 15); + // average nucleus + READ_EOSTABLE_HDF5("Abar", 16); + READ_EOSTABLE_HDF5("Zbar", 17); + // Gamma + READ_EOSTABLE_HDF5("gamma", 18); + + // Read additional tables and variables + READ_EOS_HDF5("logrho", logrho, H5T_NATIVE_DOUBLE, H5S_ALL); + READ_EOS_HDF5("logtemp", logtemp, H5T_NATIVE_DOUBLE, H5S_ALL); + READ_EOS_HDF5("ye", ye, H5T_NATIVE_DOUBLE, H5S_ALL); + READ_EOS_HDF5("energy_shift", &energy_shift, H5T_NATIVE_DOUBLE, H5S_ALL); + + H5Fclose(file); + + // Give all values to fortran - which will copy them until I can find out how + // I can tell Fortran to use those pointers inside the module + CCTK_FNAME(allocate_eosmodule) + (&nrho, &ntemp, &nye, alltables, logrho, logtemp, ye, &energy_shift); + + // Free the memory again because fortran copied the whole thing now + free(ye); + free(logtemp); + free(logrho); + free(alltables); + +} + Directory: /trunk/src/ ====================== File [modified]: EOS_Omni_Startup.F90 Delta lines: +0 -11 =================================================================== --- trunk/src/EOS_Omni_Startup.F90 2011-10-25 18:45:07 UTC (rev 53) +++ trunk/src/EOS_Omni_Startup.F90 2011-11-13 15:50:01 UTC (rev 54) @@ -22,15 +22,4 @@ hybrid_k2_cgs = hybrid_k1_cgs * & (hybrid_rho_nuc * inv_rho_gf)**(hybrid_gamma1-hybrid_gamma2) - if(nuceos_read_table.ne.0) then - ! call EOS table reader - call CCTK_FortranString(fslen,nuceos_table_name,eosfilename) - call CCTK_INFO("##################################################") - call CCTK_INFO("EOS_Omni: Reading finite-T nuclear EOS table") - call CCTK_INFO(eosfilename) - call CCTK_INFO("##################################################") - call nuc_eos_readtable(eosfilename) - endif - - end subroutine EOS_Omni_Startup Directory: /trunk/ ================== File [modified]: param.ccl Delta lines: +1 -1 =================================================================== --- trunk/param.ccl 2011-10-25 18:45:07 UTC (rev 53) +++ trunk/param.ccl 2011-11-13 15:50:01 UTC (rev 54) @@ -58,7 +58,7 @@ ################ Finite-Temperature Nuclear EOS -BOOLEAN nuceos_read_table "Read in EOS table?" STEERABLE=ALWAYS +BOOLEAN nuceos_read_table "Read in EOS table?" STEERABLE=RECOVER { } "No" File [modified]: schedule.ccl Delta lines: +9 -0 =================================================================== --- trunk/schedule.ccl 2011-10-25 18:45:07 UTC (rev 53) +++ trunk/schedule.ccl 2011-11-13 15:50:01 UTC (rev 54) @@ -6,3 +6,12 @@ LANG: Fortran OPTIONS: global } "Set up conversion factors and other fun stuff" + +if (nuceos_read_table) +{ + SCHEDULE EOS_OMNI_ReadTable AT CCTK_INITIAL before ADMBase_InitialData + { + LANG: C + } "Read EOS HDF5 table" +} +

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 190)
by knarf＠cct.lsu.edu 13 Nov '11

13 Nov '11

User: knarf Date: 2011/11/13 01:23 AM Added: /cactus-benchmarks/ plot_defaults.py, results-best.py Log: started working on this figure Directory Changes: Directory: /svn:executable/ =========================== + * Directory: /svn:special/ ======================== + * File Changes: Directory: /cactus-benchmarks/ ============================== File [added]: plot_defaults.py Delta lines: +1 -0 =================================================================== --- cactus-benchmarks/plot_defaults.py (rev 0) +++ cactus-benchmarks/plot_defaults.py 2011-11-13 07:23:23 UTC (rev 190) @@ -0,0 +1 @@ +link ../plot_defaults.py \ No newline at end of file Property changes on: cactus-benchmarks/plot_defaults.py ___________________________________________________________________ File [added]: results-best.py Delta lines: +73 -0 =================================================================== --- cactus-benchmarks/results-best.py (rev 0) +++ cactus-benchmarks/results-best.py 2011-11-13 07:23:23 UTC (rev 190) @@ -0,0 +1,73 @@ +#!/usr/bin/python + +# Plot evolution of central density +from plot_defaults import * + +# todo: Zeilenabstand Legende +# X-Achse in 2^x beschriften + + +# stuff +xlim = (10,15000) +ylim = (0,40) + +# load data +def load_machine(machine, filters): + steps,size,procs,ppn,tpp,itera,walltime = np.loadtxt("results-"+machine+".out", comments="#", usecols=(1,2,4,5,6,7,8), unpack=True) + fields={'steps' : 0, + 'size' : 1, + 'procs' : 2, + 'ppn' : 3, + 'tpp' : 4, + 'iter' : 5, + 'walltime' : 6, + } + for field in filters: + (steps,size,procs,ppn,tpp,itera,walltime)=np.array(filter(lambda x: + eval('x['+str(fields[field])+']'+filters[field]), + np.array([steps,size,procs,ppn,tpp,itera,walltime]).T)).T + return (procs, walltime/25**3/128/2/4*1.e6) + +# Plot basics +fig = plt.figure(figsize=(6, 3)) +fig.subplots_adjust(top=0.85, bottom=0.16, left=0.11,right=0.97) +ax = fig.add_subplot(1,1,1) + +# plot +Fx,Fy = load_machine('franklin', {'steps': '==128', 'size': '==25', 'procs': '>=16', 'tpp': '==1', 'iter': '==0'}) +ax.semilogx(Fx, Fy, linestyle='-', marker='+', color='red', label='Franklin') + +Fx,Fy = load_machine('hlrb2', {'steps': '==128', 'size': '==25', 'procs': '>=16', 'tpp': '==1', 'iter': '==10'}) +ax.semilogx(Fx, Fy, linestyle='--', marker='x', color='green', label='HLRB II') + +Fx,Fy = load_machine('kraken', {'steps': '==128', 'size': '==25', 'ppn': '==4', 'procs': '>=16', 'tpp': '==1', 'iter': '==50'}) +ax.semilogx(Fx, Fy, linestyle='--', marker='*', color='blue', label='Kraken') + +Fx,Fy = load_machine('queenbee', {'steps': '==128', 'size': '==25', 'ppn': '==8', 'procs': '>=16', 'tpp': '==2', 'iter': '==0'}) +ax.semilogx(Fx, Fy, linestyle='--', marker='s', color='purple', label='Queen Bee') + +Fx,Fy = load_machine('ranger', {'steps': '==128', 'size': '==25', 'ppn':'==16', 'procs': '>=16', 'tpp': '==1', 'iter': '==71'}) +ax.semilogx(Fx, Fy, linestyle='-', marker='s', color='black', label='Ranger') + +# plot properties +ax.set_xlim(xlim) +ax.set_ylim(ylim) + +#plt.title('PSD', fontsize=fontsize) + +ax.set_xlabel(r'Number of cores') +#ax.xaxis.set_major_locator(mticker.MaxNLocator(7)) +#ax.xaxis.set_minor_locator(mticker.MaxNLocator(14)) +ax.xaxis.grid(False) +ax.set_ylabel(r'time per RHS evalutation $[\mu s]$') +ax.yaxis.set_major_locator(mticker.MaxNLocator(5)) +ax.yaxis.set_minor_locator(mticker.MaxNLocator(10)) +ax.yaxis.grid(False) +set_tick_sizes(ax, 8, 4) + +handles, labels = ax.get_legend_handles_labels() +leg = ax.legend(handles, labels, loc='best', handlelength=4) + +#plt.show() +plt.savefig('test.pdf') + Property changes on: cactus-benchmarks/results-best.py ___________________________________________________________________

1 0

[svn:einsteintoolkit] GRHydro/trunk/doc/ (Rev. 299)
by knarf＠cct.lsu.edu 13 Nov '11

13 Nov '11

User: knarf Date: 2011/11/13 01:18 AM Modified: /trunk/doc/ documentation.tex Log: some updates to the documentation File Changes: Directory: /trunk/doc/ ====================== File [modified]: documentation.tex Delta lines: +24 -68 =================================================================== --- trunk/doc/documentation.tex 2011-11-04 18:34:36 UTC (rev 298) +++ trunk/doc/documentation.tex 2011-11-13 07:18:46 UTC (rev 299) @@ -122,13 +122,15 @@ at the EU Network meeting in Southampton that gave the right answer thanks to a little bit of help from the authors of the code after some slight irregularities on the part of certain specialists in - strange stars.} code is a product of the EU Network on Sources of -Gravitational Radiation\footnote{http://www.eu-network.org}. It was initially written by Luca Baiotti, Ian Hawke -and Pedro Montero, based on the publicly available {\tt GR3D} code and with many other important -contributors. + strange stars.} code is based upon the public version of the {\tt Whisky} code which + is a product of the EU Network on Sources of + Gravitational Radiation\footnote{http://www.eu-network.org}, + and was initially written by Luca Baiotti, Ian Hawke + and Pedro Montero, based on the publicly available {\tt GR3D} code and + with many other important contributors. + With the help of large parts of the community, the {\tt GRHydro} code got + improved, extended and included into the Einstein Toolkit. - - \section{Using This Thorn} \label{sec:use} @@ -141,12 +143,9 @@ \begin{verbatim} http://www.einsteintoolkit.org \end{verbatim} -as well as the original {\tt Whisky} website at -\begin{verbatim} -http://www.whiskycode.org -\end{verbatim} -{\tt GRHydro} provides the hydro variables and methods to evolve them. It +{\tt GRHydro} uses the hydro variables defined in {\tt HydroBase} +and provides own ``conserved'' hydro variables and methods to evolve them. It does not provide any information about initial data or equations of state. For these, other thorns are required. A minimal list of thorns for performing a shock-tube test is given in the shock-tube test @@ -156,20 +155,16 @@ \end{verbatim} and will include the essential thorns \begin{verbatim} -GRHydro eos_base admbase admcoupling mol +GRHydro EOS_Omni ADMBase ADMCoupling MoL \end{verbatim} -Current thorns actually implementing equations of state include -\begin{verbatim} -eos_ideal_fluid eos_polytrope -\end{verbatim} Initial data for shocks can be set using \begin{verbatim} -GRHydro_init_data +GRHydro_Init_Data \end{verbatim} Initial data for spherically symmetric static stars (with perturbations or multiple ``glued'' stars) can be set by \begin{verbatim} -GRHydro_tovsolverc +TOVSolver \end{verbatim} The actual evolution in time is controlled by the Method of Lines @@ -223,8 +218,6 @@ The public version of GRHydro can be found on the website {\tt http://www.einsteintoolkit.org}. -The latest public version of Whisky can be found on the -website {\tt http://www.whiskycode.org}. \subsection{Basic Usage} @@ -255,7 +248,7 @@ have compiled in. \item Initial data parameters: {\tt GRHydro\_rho\_central} is inherited by many initial data thorns to set the central density of compact fluid - objects such as single stars. + objects such as single stars. However, this parameter is depreciated. \item Atmosphere parameters: Many of these are listed in section~\ref{sec:atmosphere}. \end{itemize} @@ -280,16 +273,12 @@ the {\tt MoL} evolution method without change. This (currently) allows for up to fourth-order accuracy in time without any changes to {\tt GRHydro}. -For the general equations of state {\tt GRHydro} uses the {\tt EOS\_Base} +For the general equations of state {\tt GRHydro} uses the {\tt EOS\_Omni} interface. This returns the necessary hydrodynamical quantities, such as the pressure and derivatives with general function calls. The parameter {\tt GRHydro\_eos\_table} controls which equation of state is -used during evolution. +used during evolution. -{\tt GRHydro} also explicitly depends on the polytropic equation of state -thorn {\tt EOS\_Polytrope}. This is used to reset the hydrodynamical -quantities in the atmosphere if necessary. - For the metric quantities {\tt GRHydro} uses the standard {\tt CactusEinstein} arrangement, especially {\tt ADMBase}. This allows the standard thorns to be used for the calculation of constraint @@ -298,44 +287,14 @@ \subsection{Support and Feedback} -The {\tt GRHydro} web page is located at +{\tt GRHydro} is part of the Einstein Toolkit, with its web page located at \begin{verbatim} http://www.einsteintoolkit.org \end{verbatim} -and contains information on obtaining the code, together with -thornlists and sample parameter files. There is also a section on -Frequently Asked Questions which will hopefully solve your problem. -If your problem is not answered there then please send details to one -of the maintainers listed below. +It contains information on obtaining the code, together with +thornlists and sample parameter files. For questions, send an email +to the Einstein Toolkit mailing list {\tt users(a)einsteintoolkit.org}. -The primary maintainers of {\tt GRHydro} are Ian Hawke ({\tt - hawke(a)aei.mpg.de}), Luca Baiotti ({\tt baiotti(a)yukawa.kyoto-u.ac.jp}) and Frank L\"offler -({\tt knarf(a)cct.lsu.edu}). Email should always reach us faster than -other means and we will try to fix any problems as fast as possible. -Problems with the web page should also be addressed to Frank. - -Other people with knowledge and experience of developing and using -{\tt GRHydro} who may be able to help include Luciano Rezzolla ({\tt - rezzolla(a)aei.mpg.de}) and Nick Stergioulas ({\tt niksterg(a)aei.mpg.de}). - -Problems with thorns that {\tt GRHydro} depends on should go direct to their -maintainers. Examples would be -\begin{itemize} -\item {\tt MoL}: Ian Hawke ({\tt hawke(a)aei.mpg.de}) -\item {\tt ADM\_BSSN}: Denis Pollney ({\tt pollney(a)aei.mpg.de}) or Ian Hawke ({\tt - hawke(a)aei.mpg.de}) -\item {\tt ADMBase, ADMCoupling, StaticConformal}: The Cactus team - ({\tt cactusmaint(a)cactuscode.org}) -\item {\tt EOS\_*}: Ian Hawke (although in this case I can't guarantee - I'll be able to fix the problem) -\item {\tt GRHydro\_Init\_Data}: Luca Baiotti ({\tt baiotti(a)yukawa.kyoto-u.ac.jp}) or - Ian Hawke ({\tt hawke(a)aei.mpg.de}) -\item {\tt GRHydro\_TOVSolverC}: Ian Hawke ({\tt hawke(a)aei.mpg.de}) or Frank L\"offler ({\tt - knarf(a)cct.lsu.edu}) -\item {\tt GRHydro\_IVP}: Frank L\"offler ({\tt knarf(a)cct.lsu.edu}) - or Luca Baiotti ({\tt baiotti(a)yukawa.kyoto-u.ac.jp}) or Ian Hawke ({\tt hawke(a)aei.mpg.de}) -\end{itemize} - \section{Physical System} \label{sec:phys} @@ -1981,7 +1940,8 @@ \item ~1998-: Developed as Cactus thorn {\tt MAHC} inside the GR{\tt Astro\_Hydro} arrangement at Washington University, primarily by Mark Miller. -\item 2002-: {\tt Whisky} written based on {\tt GR3D}. +\item 2002-2008: {\tt Whisky} written based on {\tt GR3D}. +\item 2008-: {\tt GRHydro} based on the public version of {\tt Whisky} \end{itemize} This is necessarily only a sketch; many people have contributed to @@ -2009,11 +1969,6 @@ %\item The use of the equation of state, in particular the routines to % ensure the initial hydrodynamic consistency, were due to the work of % Harald Dimmelmeier and Christian Ott. -\item The initial value solver {\tt GRHydro\_IVP} was initially a - rewrite of the IVP solver written by Washington University (Malcolm - Tobias?) based on the formulation given by the Living Review of - Cook~\cite{Cook00}. For actually making it work thanks are due to - Frank L\"offler and Luca Baiotti. \end{itemize} \subsection{Thorn Documentation} @@ -2044,7 +1999,8 @@ EU Network, especially Toni Font, Luciano Rezzolla, Nick Stergioulas, Ed Seidel, Carsten Gundlach and Jos\'e-Maria Ib{\'a}{\~n}ez. -Originally Ed Seidel and then Luciano Rezzolla have been granting (in addition to valuable +Originally Ed Seidel and then Luciano Rezzolla and Gabrielle Allen and many others +have been granting (in addition to valuable scientific advice) financial support and human resources to the development of the code. \begin{thebibliography}{20}

1 0

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

11 Nov '11

User: rhaas Date: 2011/11/11 10:02 PM Modified: / ET.tex Log: work through Christian's suggestions until section '4. Core Technologies' some paper references would be easiest of someone would speak up if (a) they use many cores in there simulations (the more the better) (b) know the old papers introducing Cactus (one written by LSU, AEI & NCSA members) File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +43 -32 =================================================================== --- ET.tex 2011-11-12 00:34:24 UTC (rev 188) +++ ET.tex 2011-11-12 04:02:46 UTC (rev 189) @@ -346,34 +346,42 @@ \section{Core Technologies} -The Einstein Toolkit consists of many 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, and four -are described in more detail below: the {\tt Cactus} framework, providing the -underlying infrastructure of which many other components make use, -adaptive mesh refinement drivers, -without which most results could not be 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. +The Einstein Toolkit modules center around a set of core modules that provide +basic functionality to create, deploy and manage a numerical simulation +starting with code generation all to way to archiving of simulation +results: (i) the {\tt Cactus} framework ``flesh'' provides the underlying +infrastructure to build complex simulation codes out of independently +developed modules and facillates communication between these modules. (ii) the +adaptive mesh refinement driver, {\tt Carpet}, is build on top of {\tt Cactus} +and provides problem independent adaptive mesh refinement support for +simulations that need to resolve physics on length scales differing by many +orders of magnitude, while relieving the scientist of the need to worry about +internal details of the mesh refinement driver. (iii) {\tt Kranc}, which generates +code in a computer language from a high-level description in Mathematica and +(iv) the Simulation Factory, which provides a uniform, high-level interface to +common operations, such submisson and restart of jobs, for a large number of +compute clusters. \subsection{Cactus Framework} The {\tt Cactus} Framework~\cite{Cactuscode:web,Goodale:2002a,CactusUsersGuide:web} is an open source, modular, portable programming environment for -collaborative HPC computing, primarily developed at Louisiana State University\@. +collaborative HPC computing, primarily developed at Louisiana State University, +and historically at the Albert Einstein Institute and the +National Center for Supercomputing Applications~\todo{RH: for the senior +people: is there a citable paper or somthing similar that docuemnts NCSA's +involvement in Cactus?}. The {\tt Cactus} computational toolkit consists of general modules providing parallel drivers, coordinates, boundary conditions, interpolators, reduction operators, and efficient I/O in different data formats. Generic interfaces are used, making it possible to use external packages and improved modules which are immediately available -to its users. {\tt Cactus} is involved in the NSF Blue Waters consortium -for petascale computing, and has funding from NSF SDCI to -develop new application-level tools for performance and correctness. +to its users. The structure of the {\tt Cactus} framework is completely modular, with -only a very small core providing the interfaces between modules, +only a very small core (the ``flesh'') providing the interfaces between +modules, both at compile- and run-time. The {\tt Cactus} modules, called ``thorns'', may, and typically do, specify inter-module dependencies, e.g., to share or extend configuration information, common variables, or runtime parameters. @@ -390,15 +398,16 @@ The {\tt Cactus} Framework was developed by the numerical relativity community, and although it is a general component framework that supports different application domains its core user -group has remained from numerical relativity. The {\tt Cactus} team has -traditionally developed and supported a set of core modules for numerical -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 distributed by research -groups within the community. -The Einstein Toolkit now collects the widely used parts of CactusEinstein, -combined with contributions from the community. +group continues to be comprised of numerical relativists. +It is not surprising therefore, that one of the science modules provided in +the Einstein Toolkit is a set of state of the art modules to simulate binary +black hole mergers. All modules to simulate and analyse the data are provided +out of the box. This set of modules also provides a way of testing the +Einstein Toolkit modules in a production type simulation rather than synthetic +test cases. Some of these modules have been developed specifically for the +Einstein Toolkit while others are modules used in previous publications and +have been contributed to the toolkit. In these cases the Einstein Toolkit +provides documenation and best practise guidelines for the contributed modules. \subsection{Adaptive Mesh Refinement} @@ -416,14 +425,14 @@ The Einstein Toolkit offers two drivers, \codename{PUGH} and {\tt Carpet}. \codename{PUGH} provides domains consisting of a uniform grid with Cartesian topology, and is highly scalable (up to more than -130,000 cores on a Blue Gene/P~\cite{Cactuscode:BlueGene:web}.) +130,000~\cite{Cactuscode:BlueGene:web}.) {\tt Carpet}~\cite{Schnetter:2003rb, Schnetter:2006pg, CarpetCode:web} provides multi-block methods and adaptive mesh refinement (AMR\@). Multi-block methods cover the domain with a set of (possibly distorted) blocks that exchange boundary information via techniques such as interpolation or penalty methods.\footnote{Although multi-block methods are supported by {\tt Carpet}, the Einstein Toolkit itself - does not yet + does not currently contain any multi-block coordinate systems.} The AMR capabilities employ the standard Berger-Oliger algorithm~\cite{Berger:1984zza} with subcycling in time. @@ -473,7 +482,8 @@ {\tt Carpet} is the main driver used today for {\tt Cactus}-based astrophysical simulations. {\tt Carpet} offers hybrid MPI/OpenMP parallelization and is -used in production on up to several thousand cores. +used in production on up to several thousand cores~\cite{Reisswig:2010cd,Lousto:2010ut}. +\todo{if you use many cores in your runs: please speak up} \begin{figure} \centering \includegraphics[width=0.5\textwidth]{cactus-benchmarks/results-best} @@ -491,15 +501,16 @@ where \texttt{McLachlan} (see section \ref{sec:Kevol} below) solves the Einstein equations on a grid structure with nine levels of mesh refinement. This demonstrates excellent -scalability up to more than ten thousand cores. (In production -simulations, smaller and more complex grid structures and other -necessary tasks reduce scalability by about a factor of ten.) +scalability up to more than ten thousand cores. In production +simulations, smaller and more complex grid structures, serial +tasks related to online data analysis and other +necessary tasks reduce scalability by up to a factor of ten. We estimate that, in 2010, about 7,000 core years of computing time (45 million core hours) were used via {\tt Carpet} by more than a dozen research groups world-wide. To date, more than 90 peer-reviewed publications and more -than 15 student theses are based on {\tt Carpet}~\cite{CarpetCode:web}. +than 15 student theses have been based on {\tt Carpet}~\cite{CarpetCode:web}. \subsection{Simulation Factory} @@ -518,7 +529,7 @@ The Simulation Factory~\cite{Thomas:2010aa, SimFactory:web} offers a set of abstractions for the tasks necessary to set up and successfully -finish numerical simulations based on the {\tt Cactus} framework. These +complete numerical simulations based on the {\tt Cactus} framework. These abstractions hide tedious low-level management operations, they capture ``best practices'' of experienced users, and they create a log trail ensuring repeatable and well-documented scientific results.

1 0

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

11 Nov '11

User: rhaas Date: 2011/11/11 06:34 PM Modified: / ET.tex Log: define quantities in ns collapse add some comments wrt Christian comments start working (from the end) on the issues in ETcomments.pdf File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +18 -4 =================================================================== --- ET.tex 2011-11-11 21:06:36 UTC (rev 187) +++ ET.tex 2011-11-12 00:34:24 UTC (rev 188) @@ -539,6 +539,8 @@ The Simulation Factory supports and simplifies three kinds of operations: +%RH: any of the itemize, decription, enumerate environments indents its body +%by the same amount as \parindent \begin{description} \item[Remote Access] The actual access commands and authentication methods differ between systems, as do the user names that a person @@ -2681,7 +2683,7 @@ polytropic constant $K_{\mathrm{ID}}$ from its initial value to $K = 0.98 \, K_{\mathrm{ID}} = 98$. To ensure that the pressure depleted configuration remains a solution of the Einstein constraint -equations (Eq.~\ref{eqn:analysis_hamiltonian_constraint}) in the presence +equations~\eref{eqn:analysis_hamiltonian_constraint} in the presence of matter we rescale the rest mass density $\rho$ such that the total energy density $T_{nn}$ %\todo{RH: unify notation of $\rho$} @@ -2752,15 +2754,27 @@ circumferential radius, whereas the meaning of the coordinate radius in our BSSN calculation is closer to a radius in isotropic gauge \todo{Roland, do you agree?}. - +\todo{RH: TOVSolver sets up isotropic coordinates initially, at the end of the +simulation though I have sizeable off-diagonal metric components (gxy is about +0.2 within 6M) and also a non-zero shift, the metric diagonal elements are also not +idenical. So the coordinate system is no longer obviously isotropic as far as I +can tell. On the other hand it is also not just Schwarzschild coordinates +transformed to Cartesian coordinates using the flat space expressions for r, +$\theta$ and $\phi$. So I +agree the the coordinates are likely not Schwarzschild coordinates but am not +sure that they are still isotropic since the direction towards the center is +special. So I'd add a weaker statement ``\ldots in our BSSN calculation is not +necessarily that of a circumferential radius''} In Figure~\ref{fig:tov_collapse_H_convergence_at0}, we display the convergence factor obtained from \begin{equation} - Q = \frac{H_{h_1}-H_{h_2}}{H_{h_2}-H_{h_3}} = \frac{h_1^Q-h_2^Q}{h_2^Q-h_3^Q}\,, + \frac{H_{h_1}-H_{h_2}}{H_{h_2}-H_{h_3}} = \frac{h_1^Q-h_2^Q}{h_2^Q-h_3^Q}\,, \label{eq:convergence-factor-definition} \end{equation} -where ... \todo{Roland, define H, h and subscripts} for the Hamiltonian constraint violation at the center of the collapsing star. +Here $H_{h_i}$ is the Hamiltonian constraint +violation~\eref{eqn:analysis_hamiltonian_constraint} at the center of the +star for a run with resolution $h_i$. Up to the time when the apparent horizon forms, the convergence order is $\approx 1.5$ as expected. At later times, the singularity forming at the center of the collapsing star renders a pointwise measurement of the

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 187)
by jfaber＠einsteintoolkit.org 11 Nov '11

11 Nov '11

User: jfaber Date: 2011/11/11 03:06 PM Modified: / ET.tex Log: Reworked list of NSNS and BHNS refs by topic, not by group per Christian's suggestion Moved scientific developments yet to occur from Sec. 2.1 into conclusions, might need to be trimmed a bit File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +71 -106 =================================================================== --- ET.tex 2011-11-11 16:18:21 UTC (rev 186) +++ ET.tex 2011-11-11 21:06:36 UTC (rev 187) @@ -213,42 +213,19 @@ Many of the successful techniques used to evolve BH-BH binaries have proven to be equally applicable to merging -NS-NS and BH-NS binaries (see, e.g.,~\cite{Faber:2009zz,Duez:2009yz} for reviews), allowing for further investigations into the former +NS-NS \cite{Anderson:2007kz,Anderson:2008zp,Baiotti:2008ra,Baiotti:2009gk,Baiotti:2010xh, +Baiotti:2011am,Bernuzzi:2011aq,Giacomazzo:2009mp, +Giacomazzo:2010bx,Gold:2011df,Hotokezaka:2011dh,Kiuchi:2009jt, Kiuchi:2010ze,Liu:2008xy,Rezzolla:2010fd,Rezzolla:2011da,Sekiguchi:2011zd,Sekiguchi:2011mc,Thierfelder:2011yi,Yamamoto:2008js} and BH-NS \cite{Chawla:2010sw,Duez:2008rb,Duez:2009yy,Etienne:2007jg,Etienne:2008re,Foucart:2010eq,Foucart:2011mz,Kyutoku:2010zd,Kyutoku:2011vz,Lackey:2011vz,Loffler:2006nu,Shibata:2006bs, +Shibata:2006ks,Shibata:2007zm,Shibata:2009cn, +Shibata:2010zz,Stephens:2011as,Yamamoto:2008js} binaries (for reviews, see also~\cite{Faber:2009zz,Duez:2009yz}), allowing for further investigations into the former and the first full GR simulations of the latter. All recent results use either the general harmonic formalism or the BSSN formalism in the ``moving puncture'' gauge. Nearly all include some form of adaptive mesh refinement, since unigrid models cannot produce accurate long-term evolutions -without requiring exorbitant computational resources. Many groups' codes +without requiring exorbitant computational resources, though some BH-NS simulations have been performed with a pseudospectral code \cite{Duez:2008rb,Duez:2009yy,Foucart:2010eq,Foucart:2011mz}. Many groups' codes now include GRMHD (used widely for NS-NS mergers, and for BH-NS mergers in~\cite{Chawla:2010sw}, and some include microphysical effects as -well~(e.g.,\cite{Duez:2009yy,Sekiguchi:2011zd}). -\todo{CDO: I think we should -get completely rid of this; it's impossible to get it right and -misleading. For example, there is the spec guys and me at Caltech; -there is Burrows and Pretorius at Princeton, there is now CITA and -WSU etc. Not at all a good idea to put this in writing.} -The groups that have reported simulations of NS-NS or BH-NS mergers include: -\begin{itemize} -\item {\bf AEI/Sissa}: BH-NS mergers using GRHD~\cite{Loffler:2006nu} and NS-NS -mergers using GRHD~\cite{Baiotti:2008ra,Baiotti:2009gk,Baiotti:2010xh, -Baiotti:2011am,Rezzolla:2010fd} and GRMHD~\cite{Giacomazzo:2009mp, -Giacomazzo:2010bx,Rezzolla:2011da}. -\item {\bf Caltech/Cornell}: A {\em pseudospectral}, GRHD code has been used -to simulate BH-NS mergers~\cite{Duez:2008rb,Duez:2009yy,Foucart:2010eq}. -\item {\bf Illinois}: BH-NS mergers using GRHD~\cite{Etienne:2007jg,Etienne:2008re} -and NS-NS mergers using GRMHD~\cite{Liu:2008xy}. -\item {\bf Jena}: NS-NS mergers using GRHD~\cite{Thierfelder:2011yi}. -\item {\bf LSU/BYU/LIU}: BH-NS mergers using GRMHD~\cite{Chawla:2010sw} and -NS-NS mergers using GRHD~\cite{Anderson:2007kz} -and GRMHD~\cite{Anderson:2008zp}. -\item {\bf Princeton}: BH-NS mergers using GRHD~\cite{Stephens:2011as}. -\item {\bf Tokyo/Kyoto}: BH-NS mergers using GRHD~\cite{Shibata:2006bs, -Shibata:2006ks,Shibata:2007zm,Yamamoto:2008js,Shibata:2009cn, -Kyutoku:2010zd,Shibata:2010zz} and NS-NS mergers using GRHD -\cite{Yamamoto:2008js,Kiuchi:2009jt, Kiuchi:2010ze,Hotokezaka:2011dh}, -most recently with the inclusion of neutrino cooling~\cite{Sekiguchi:2011zd}. -\todo{Check for updates to list before submission!} -\end{itemize} +well~(e.g.,\cite{Duez:2009yy,Sekiguchi:2011zd,Sekiguchi:2011mc}). In addition to studying binary mergers, numerical relativity is a necessary element for understanding stellar collapse and dynamical instabilities @@ -261,7 +238,7 @@ rapidly rotating polytropic NS models~\cite{Shibata:1999yx,Baiotti:2006wn, Manca:2007ca}. -Simultanious to the advances in both our physical understanding of +Simultaneously with the advances in both our physical understanding of relativistic dynamics and the numerical techniques required to study them, a set of computational tools and libraries has been developed with the aim of providing a computational core that can enable new science, @@ -299,80 +276,17 @@ One of the aims of the Einstein Toolkit is to provide or extend some of these missing ingredients in the course of its development. -The three most important of all possible additions, as deemed by -the Einstein Toolkit members, are listed below: +Over the past three years, routines have been added to the code to allow for a wider range of initial data choices, +to allow for multithreading in hydrodynamic evolutions, and to refine the {\tt Carpet} adaptive mesh refinement +driver. Looking forward, +three possible additions to future releases are the inclusion of magnetic fields +into the dynamics via an ideal MHD treatment, more physical nuclear matter +equations of state (EOSs) including the ability to model finite-temperature effects, +and higher-order numerical techniques. All of these are under active development, +with MHD and finite-temperature evolution code already available, though not completely +documented, within the public toolkit releases, and will be made available once they are +thoroughly tested and validated against known results. -\begin{itemize} - \item{\bf MHD}. Many studies, in particular those concerned with - massive star collapse, NS-NS or BH-NS binaries and rotational - non-axisymmetric instabilities, are still performed in pure GRHD\@. - Without a doubt, these systems must be simulated with GRMHD to capture - the effects of magnetic fields which in many cases will - alter the simulation outcome on a qualitative level and may be - the driving mechanisms behind much of the observable EM signature - from GRBs (e.g.,~\cite{Woosley:2006fn}) - and magneto-rotationally exploding core-collapse supernovae - (e.g.,~\cite{Burrows:2007yx}). In addition, all simulations that have - taken magnetic fields into account are still limited to the - ideal MHD approximation, which assumes perfect conductivity. - Non-ideal GRMHD schemes are just becoming - available~(see, e.g.,~\cite{Palenzuela:2008sf,DelZanna:2007pk}), - but have yet to be implemented widely in many branches of numerical relativity. - - \item {\bf Equation of state (EOS), microphysics, and radiation - transport}. Most presently published 3D GR(M)HD simulations, with the - exception of recent work on massive star collapse - (see, e.g.,~\cite{Ott:2006eu}) and binary mergers - (see, e.g.,~\cite{Sekiguchi:2011zd}), - relied on simple zero-temperature descriptions of - NS stellar structure, with many assuming simple polytropic forms. - Such EOSs are computationally - efficient, but are not necessarily a good description for matter in - relativistic astrophysical systems. The inclusion of - finite-temperature EOSs, derived from the microphysical descriptions of - high-density matter, will lead to qualitatively different and much - more astrophysically reliable results (see, e.g.,~\cite{Ott:2006eu}). - In addition, most GR(M)HD studies - neglect transport of neutrinos and photons - and their interactions with matter. Neutrinos in - particular play a crucial role in core-collapse supernovae and in - the cooling of NS-NS merger remnants, thus they must not be left out when - attempting to accurately model such events. Few studies have - incorporated neutrino and/or photon transport and interactions in - approximate ways (see, e.g.,~\cite{Ott:2006eu,Farris:2008fe,Sekiguchi:2011zd}). - - \item {\bf High-order schemes and AMR\@}. Numerical accuracy is a - central issue in long-term GR(M)HD simulations and must be addressed - by a combination of (1) adaptive mesh refinement (AMR), which is used to focus - grid points on regions where finer resolution is needed, and (2) - high-order numerical techniques. - -Several AMR codes, including the {\tt Carpet} driver~\cite{CarpetCode:web} -included in the Einstein Toolkit, -are publicly available. An important task going forward is - to facilitate the coupling of existing and future GRMHD codes - with AMR to avoid under-resolving the - dynamics in the systems under investigation. AMR methods are - often much more complicated than uniformly distributed - mesh methods, and require sophisticated algorithms to make use of - massively parallel systems efficiently. - - While AMR can increase resolution near regions of interest within - the computational domain, it does not increase the convergence - order of the underlying numerical methods. Simulations of BHs - can easily make use of high-order numerical methods, with eighth-order - convergence commonly seen at present. However, - most GRMHD schemes, while implementing high-resolution - shock-capturing methods, - are still limited to 2nd-order numerical accuracy in the - hydrodynamic/MHD sector while performing - curvature evolution with 4th-order accuracy or more. Higher order - GRMHD schemes are in use in fixed-background simulations - (e.g.,~\cite{Tchekhovskoy:2007zn}), but still await implementation in - fully dynamical simulations. -\end{itemize} - - \subsection{Academic and Social} A primary concern for research groups is securing reliable funding @@ -2901,8 +2815,8 @@ \label{fig:kasner}} \end{figure} - \section{Conclusion and Future Work} + In this article, we described the Einstein Toolkit, a collection of freely available and easy-to-use computational codes for numerical relativity and relativistic astrophysics. The code details and example @@ -2924,8 +2838,45 @@ neutrinos, and photons will be necessary and will need to be matched by improvements in infrastructure (e.g., more flexible AMR on general grids) and computing hardware for the required fully coupled 3-D, -multi-scale, multi-physics simulations to become reality. +multi-scale, multi-physics simulations to become reality. These tasks, +as well as the others mentioned below, are likely to occupy a great deal of the +effort spent developing future versions of the Einstein Toolkit over the next few years. + Without a doubt, collapsing stars and merging BH-NS and NS-NS binaries must be simulated with GRMHD to capture + the effects of magnetic fields that in many cases will + alter the simulation outcome on a qualitative level and may be + the driving mechanisms behind much of the observable EM signature + from GRBs (e.g.,~\cite{Woosley:2006fn}) + and magneto-rotationally exploding core-collapse supernovae + (e.g.,~\cite{Burrows:2007yx}). To date, all simulations that have + taken magnetic fields into account are still limited to the + ideal MHD approximation, which assumes perfect conductivity. + Non-ideal GRMHD schemes are just becoming + available~(see, e.g.,~\cite{Palenzuela:2008sf,DelZanna:2007pk}), + but have yet to be implemented widely in many branches of numerical relativity. + + Most presently published 3D GR(M)HD simulations, with the + exception of recent work on massive star collapse + (see, e.g.,~\cite{Ott:2006eu}) and binary mergers + (see, e.g.,~\cite{Sekiguchi:2011zd}), + relied on simple zero-temperature descriptions of + NS stellar structure, with many assuming simple polytropic forms. + Such EOSs are computationally + efficient, but are not necessarily a good description for matter in + relativistic astrophysical systems. The inclusion of + finite-temperature EOSs, derived from the microphysical descriptions of + high-density matter, will lead to qualitatively different and much + more astrophysically reliable results (see, e.g.,~\cite{Ott:2006eu}). + In addition, most GR(M)HD studies + neglect transport of neutrinos and photons + and their interactions with matter. Neutrinos in + particular play a crucial role in core-collapse supernovae and in + the cooling of NS-NS merger remnants, thus they must not be left out when + attempting to accurately model such events. Few studies have + incorporated neutrino and/or photon transport and interactions in + approximate ways (see, e.g.,~\cite{Ott:2006eu,Farris:2008fe,Sekiguchi:2011zd,Sekiguchi:2011mc}). + + %%% One of the desirable additions of physics is a proper treatment of %%% radiation, in particular neutrinos. Another desirable addition would be some %%% approximation of emission of electro-magnetic waves. Radiation transport is, @@ -2957,6 +2908,20 @@ cell-centered AMR, refluxing, and GRMHD is underway and will be reported in a future publication. + While AMR can increase resolution near regions of interest within + the computational domain, it does not increase the convergence + order of the underlying numerical methods. Simulations of BHs + can easily make use of high-order numerical methods, with eighth-order + convergence commonly seen at present. However, + most GRMHD schemes, while implementing high-resolution + shock-capturing methods, + are still limited to 2nd-order numerical accuracy in the + hydrodynamic/MHD sector while performing + curvature evolution with 4th-order accuracy or more. Higher order + GRMHD schemes are in use in fixed-background simulations + (e.g.,~\cite{Tchekhovskoy:2007zn}), but still await implementation in + fully dynamical simulations. + %%% CDO: We have not even talked about the current MHD implementation, %%% how can we talk about its improvement? %%%

1 0

[svn:einsteintoolkit] manifest/trunk/ (Rev. 129)
by jfaber＠einsteintoolkit.org 11 Nov '11

11 Nov '11

User: jfaber Date: 2011/11/11 03:04 PM Modified: /trunk/ einsteintoolkit.bib Log: Changed preprints to "@misc", since they format correctly that way File Changes: Directory: /trunk/ ================== File [modified]: einsteintoolkit.bib Delta lines: +10 -18 =================================================================== --- trunk/einsteintoolkit.bib 2011-11-11 20:58:38 UTC (rev 128) +++ trunk/einsteintoolkit.bib 2011-11-11 21:04:54 UTC (rev 129) @@ -553,7 +553,7 @@ year = 1984, } -@article{Bernuzzi:2011aq, +@misc{Bernuzzi:2011aq, author = "Bernuzzi, Sebastiano and Thierfelder, Marcus and Bruegmann, Bernd", title = "{Accuracy of numerical relativity waveforms from binary @@ -1172,16 +1172,14 @@ eprint = "arXiv:1007.4203 [astro-ph.HE]", } -@article{Foucart:2011mz, +@misc{Foucart:2011mz, author = "Foucart, Francois and Duez, Matthew D. and Kidder, Lawrence E. and Scheel, Mark A. and Szilagyi, Bela and others", title = "{Black hole-neutron star mergers for 10 solar mass black holes}", year = "2011", - eprint = "1111.1677", - archivePrefix = "arXiv", - primaryClass = "gr-qc", + eprint = "arXiv:1111.1677", } ##G ############################################################################ @@ -1260,14 +1258,12 @@ url = {http://edoc.mpg.de/3341}, } -@article{Gold:2011df, +@misc{Gold:2011df, author = "Gold, Roman and Bernuzzi, Sebastiano and Thierfelder, Marcus and Bruegmann, Bernd and Pretorius, Frans", title = "{Eccentric binary neutron star mergers}", year = "2011", - eprint = "1109.5128", - archivePrefix = "arXiv", - primaryClass = "gr-qc", + eprint = "arXiv:1109.5128", } @Article{Gopakumar:2007vh, @@ -1675,15 +1671,13 @@ } ##L ############################################################################ -@article{Lackey:2011vz, +@misc{Lackey:2011vz, author = "Lackey, Benjamin D. and Kyutoku, Koutarou and Shibata, Masaru and Brady, Patrick R. and Friedman, John L.", title = "{Extracting equation of state parameters from black hole-neutron star mergers. I. Nonspinning black holes}", year = "2011", - eprint = "1109.3402", - archivePrefix = "arXiv", - primaryClass = "astro-ph.HE", + eprint = "arXiv:1109.3402", } @article{Lattimer:1991nc, @@ -1697,7 +1691,7 @@ year = 1991, } -@ARTICLE{Lechner:2004cs, +@misc{Lechner:2004cs, author = {{Lechner}, C. and {Alic}, D. and {Husa}, S.}, title = "{From Tensor Equations to Numerical Code -- Computer Algebra Tools for Numerical Relativity}", eprint = {arXiv:cs/0411063}, @@ -2231,14 +2225,12 @@ doi = {10.1103/PhysRevLett.107.051102}, } -@article{Sekiguchi:2011mc, +@misc{Sekiguchi:2011mc, author = "Sekiguchi, Yuichiro and Kiuchi, Kenta and Kyutoku, Koutarou and Shibata, Masaru", title = "{Effects of hyperons in binary neutron star mergers}", year = "2011", - eprint = "1110.4442", - archivePrefix = "arXiv", - primaryClass = "astro-ph.HE", + eprint = "arXiv:1110.4442", } @article{Shibata:1995we,

1 0

[svn:einsteintoolkit] manifest/trunk/ (Rev. 128)
by jfaber＠einsteintoolkit.org 11 Nov '11

11 Nov '11

User: jfaber Date: 2011/11/11 02:58 PM Modified: /trunk/ einsteintoolkit.bib Log: Added new NSNS and BHNS references File Changes: Directory: /trunk/ ================== File [modified]: einsteintoolkit.bib Delta lines: +69 -0 =================================================================== --- trunk/einsteintoolkit.bib 2011-11-11 16:02:06 UTC (rev 127) +++ trunk/einsteintoolkit.bib 2011-11-11 20:58:38 UTC (rev 128) @@ -553,6 +553,16 @@ year = 1984, } +@article{Bernuzzi:2011aq, + author = "Bernuzzi, Sebastiano and Thierfelder, Marcus and + Bruegmann, Bernd", + title = "{Accuracy of numerical relativity waveforms from binary + neutron star mergers and their comparison with + post-Newtonian waveforms}", + year = "2011", + eprint = "arXiv:1109.3611", +} + @Article{Berti:2007nw, author = "Berti, Emanuele and Cardoso, Vitor and Gonzalez, Jose A. and Sperhake, Ulrich and Br{\"u}gmann, @@ -1162,6 +1172,18 @@ eprint = "arXiv:1007.4203 [astro-ph.HE]", } +@article{Foucart:2011mz, + author = "Foucart, Francois and Duez, Matthew D. and Kidder, + Lawrence E. and Scheel, Mark A. and Szilagyi, Bela and + others", + title = "{Black hole-neutron star mergers for 10 solar mass black + holes}", + year = "2011", + eprint = "1111.1677", + archivePrefix = "arXiv", + primaryClass = "gr-qc", +} + ##G ############################################################################ @Book{Galassi:2009, @@ -1238,6 +1260,16 @@ url = {http://edoc.mpg.de/3341}, } +@article{Gold:2011df, + author = "Gold, Roman and Bernuzzi, Sebastiano and Thierfelder, + Marcus and Bruegmann, Bernd and Pretorius, Frans", + title = "{Eccentric binary neutron star mergers}", + year = "2011", + eprint = "1109.5128", + archivePrefix = "arXiv", + primaryClass = "gr-qc", +} + @Article{Gopakumar:2007vh, author = "Gopakumar, Achamveedu and Hannam, Mark and Husa, Sascha and Br{\"u}gmann, Bernd", @@ -1626,7 +1658,34 @@ eprint = "arXiv:1008.1460 [astro-ph.HE]", } +@article{Kyutoku:2011vz, + author = "Kyutoku, Koutarou and Okawa, Hirotada and Shibata, Masaru + and Taniguchi, Keisuke", + title = "{Gravitational waves from spinning black hole-neutron + star binaries: dependence on black hole spins and on + neutron star equations of state}", + journal = "Phys. Rev. D", + volume = "84", + pages = "064018", + doi = "10.1103/PhysRevD.84.064018", + year = "2011", + eprint = "1108.1189", + archivePrefix = "arXiv", + primaryClass = "astro-ph.HE", +} + ##L ############################################################################ +@article{Lackey:2011vz, + author = "Lackey, Benjamin D. and Kyutoku, Koutarou and Shibata, + Masaru and Brady, Patrick R. and Friedman, John L.", + title = "{Extracting equation of state parameters from black + hole-neutron star mergers. I. Nonspinning black holes}", + year = "2011", + eprint = "1109.3402", + archivePrefix = "arXiv", + primaryClass = "astro-ph.HE", +} + @article{Lattimer:1991nc, author = "Lattimer, James M. and Swesty, F. Douglas", title = "{A Generalized equation of state for hot, dense @@ -2172,6 +2231,16 @@ doi = {10.1103/PhysRevLett.107.051102}, } +@article{Sekiguchi:2011mc, + author = "Sekiguchi, Yuichiro and Kiuchi, Kenta and Kyutoku, + Koutarou and Shibata, Masaru", + title = "{Effects of hyperons in binary neutron star mergers}", + year = "2011", + eprint = "1110.4442", + archivePrefix = "arXiv", + primaryClass = "astro-ph.HE", +} + @article{Shibata:1995we, author = "Shibata, Masaru and Nakamura, Takashi", title = "{Evolution of three-dimensional gravitational waves:

1 0

[svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 186)
by knarf＠cct.lsu.edu 11 Nov '11

11 Nov '11

User: knarf Date: 2011/11/11 10:18 AM Modified: / ET.tex Log: incoorperate Christians changes File Changes: Directory: / ============ File [modified]: ET.tex Delta lines: +25 -22 =================================================================== --- ET.tex 2011-11-11 15:34:53 UTC (rev 185) +++ ET.tex 2011-11-11 16:18:21 UTC (rev 186) @@ -151,30 +151,28 @@ been closely tied to the availability and ease-of-use of enabling software and computational infrastructure. This document describes the Einstein Toolkit, which provides such an infrastructure, -developed openly and available freely with support from +developed openly and made available freely with grant support from the National Science Foundation. -%under the grant numbers 0903973/0903782/0904015 (CIGR). Now is a particularly exciting time for numerical relativity and relativistic astrophysics, with major advances having been achieved in the study of astrophysical systems containing black holes (BHs) -and neutron stars (NSs). While the first fully general relativistic (GR) +and neutron stars (NSs). The first fully general relativistic (GR) simulations of merging NS-NS binaries were reported in 1999, with further advances for the next few years~\cite{Shibata:1999wm,Shibata:2002jb, -Shibata:2003ga,Shibata:2005ss,Shibata:2006nm}, systems containing BHs proved -much more numerically intractable until 2005. That year, computational -breakthroughs were made using a generalized harmonic gauge (GHG) -\cite{Pretorius:2005gq} and then a ``moving puncture'' approach +Shibata:2003ga,Shibata:2005ss,Shibata:2006nm}. However, systems containing BHs proved +much more difficult to track numerically until 2005. That year, computational +breakthroughs were made using a generalized harmonic formulation~\cite{Pretorius:2005gq} and then a ``moving puncture'' approach \cite{Campanelli:2005dd, Baker:2005vv} in the BSSN (Baumgarte-Shapiro-Shibata-Nakamura) formalism~\cite{Shibata:1995we,Baumgarte:1998te} that allowed for the first stable long-term evolutions of moving single and multiple BH systems. These results quickly transformed the field -with the ability to effectively evolve the Einstein field equations +which was now able to effectively evolve the Einstein field equations for coalescing BH-BH binaries and other systems containing moving BHs, including merging BH-NS binaries. -These breakthroughs have led to many advancements with direct relevance -to astrophysics, including exciting new results on recoil velocities +These breakthroughs had direct relevance +to astrophysics, and enabled exciting new results on recoil velocities from BH-BH mergers~(e.g, \cite{Baker:2006vn,Campanelli:2007ew,HolleyBockelmann:2007eh, Pollney:2007ss,Lousto:2007db,Lousto:2008dn} and references therein), @@ -193,37 +191,42 @@ Pfeiffer:2007yz,Stephens:2011as}. Meanwhile, general relativistic magneto-hydrodynamics (GRMHD) -on fixed background spacetimes has been implemented in multi-dimensional +on fixed background spacetimes has been successful in multi-dimensional settings since the mid-1990s, focusing on BH accretion processes and relativistic jet production and evolution (see~\cite{Font:2008aa} for a review of the numerical formalism and~\cite{Hawley2009apss} for a review of work on disk and jet models). GRMHD coupled with curvature evolution, on the other hand, which is crucial for modeling large-scale bulk -dynamics in compact binary or single-star collapse scenarios, has +dynamics in compact binary star coalescence or single-star collapse scenarios, has started to produce astrophysically interesting results only in the -past $\sim 3-5$ years, enabled primarily by the availability of the long-term -stable curvature evolution systems discussed above as well as improved GRMHD +past $\sim 3-5$ years, enabled primarily by the availability of long-term +stable curvature evolution systems as well as improved GRMHD algorithms~(see~\cite{Font:2008aa} for a review). In addition to these developments, substantial progress has been made -using physically motivated equations of state (EOS), +in importing more physically motivated equations of state (EOS), including tabulated versions (e.g.,~\cite{Pandharipande:1989hn, Douchin:2001sv,Akmal:1998cf}) and temperature-dependent models -(e.g.,~\cite{Shen:1998by,Shen:1998gq,Lattimer:1991nc}). Some codes also -incorporate microphysical effects, such as neutrino cooling -\cite{Sekiguchi:2011zd}. +(e.g.,~\cite{Shen:1998by,Shen:1998gq,Lattimer:1991nc}). Some codes +have also begun to incorporate microphysical effects of neutrino emission +and deleptonization~\cite{Sekiguchi:2011zd,O'Connor:2009vw}. Many of the successful techniques used to evolve BH-BH binaries have proven to be equally applicable to merging NS-NS and BH-NS binaries (see, e.g.,~\cite{Faber:2009zz,Duez:2009yz} for reviews), allowing for further investigations into the former and the first full GR simulations of the latter. All recent results use -either the GHG formalism (Caltech/Cornell, LSU/BYU/LIU, and Princeton) or -BSSN ``moving puncture'' gauge (or variants thereof; AEI/Sissa, Illinois, -Jena, and Tokyo/Kyoto). Nearly all include some form of adaptive mesh +either the general harmonic formalism or the +BSSN formalism in the ``moving puncture'' gauge. Nearly all include some form of adaptive mesh refinement, since unigrid models cannot produce accurate long-term evolutions without requiring exorbitant computational resources. Many groups' codes now include GRMHD (used widely for NS-NS mergers, and for BH-NS mergers -in~\cite{Chawla:2010sw}, and some include microphysical effects as well. +in~\cite{Chawla:2010sw}, and some include microphysical effects as +well~(e.g.,\cite{Duez:2009yy,Sekiguchi:2011zd}). +\todo{CDO: I think we should +get completely rid of this; it's impossible to get it right and +misleading. For example, there is the spec guys and me at Caltech; +there is Burrows and Pretorius at Princeton, there is now CITA and +WSU etc. Not at all a good idea to put this in writing.} The groups that have reported simulations of NS-NS or BH-NS mergers include: \begin{itemize} \item {\bf AEI/Sissa}: BH-NS mergers using GRHD~\cite{Loffler:2006nu} and NS-NS

1 0

[svn:einsteintoolkit] manifest/trunk/ (Rev. 127)
by schnetter＠cct.lsu.edu 11 Nov '11

11 Nov '11

User: eschnett Date: 2011/11/11 10:02 AM Modified: /trunk/ einsteintoolkit.bib Log: Formatting change File Changes: Directory: /trunk/ ================== File [modified]: einsteintoolkit.bib Delta lines: +2 -2 =================================================================== --- trunk/einsteintoolkit.bib 2011-11-11 16:00:57 UTC (rev 126) +++ trunk/einsteintoolkit.bib 2011-11-11 16:02:06 UTC (rev 127) @@ -1113,8 +1113,8 @@ and Tobias, Malcolm", title = "{Three-dimensional general relativistic hydrodynamics. 2. Long term dynamics of single relativistic stars}", - journal = "Phys.Rev.", - volume = "D65", + journal = "Phys. Rev. D", + volume = "65", pages = "084024", doi = "10.1103/PhysRevD.65.084024", year = "2002",

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Commits November 2011