Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #551: Output metadata from TwoPunctures
by Einstein Toolkit 25 Sep '11

25 Sep '11

#551: Output metadata from TwoPunctures -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: TwoPunctures | -----------------------------------+---------------------------------------- It is desirable to be able to determine the properties of !TwoPunctures initial data from the simulation output. Currently, some quantities (initial momenta etc.) can be determined by parsing the parameter file and param.ccl, and others by parsing the standard output of the run (ADM mass). Neither of these are optimal. The attached patch causes !TwoPunctures to output a metadata file in the form described in [http://arxiv.org/abs/0709.0093 Data formats for numerical relativity waves]. The keys used include current draft proposals used in the NR-AR project. To encourage the use of this, I have made the output happen unconditionally. The output filename is !TwoPunctures.bbh and it is written into IO::out_dir. The metadata file looks like this: {{{ # ================================== # Numerical Relativity Metadata file # ================================== # # This file contains information about the simulation provided by the # TwoPunctures thorn. The format is described in the NR Data Format Document # http://arxiv.org/abs/0709.0093 [draft SVN r707]. [metadata] initial-ADM-energy = 1.190594340667362472 initial-ADM-angular-momentumx = 0.1100000000000000006 initial-ADM-angular-momentumy = 0.2200000000000000011 initial-ADM-angular-momentumz = 1.195856641772157003 initial-separation = 7 initial-data-type = Bowen-York initial-data-bibtex-keys = Bowen:1980yu Brandt:1997tf Ansorg:2004ds initial-bh-position1x = 3.5 initial-bh-position1y = 0 initial-bh-position1z = 0 initial-bh-position2x = -3.5 initial-bh-position2y = 0 initial-bh-position2z = 0 initial-bh-momentum1x = -0.003358311330506950042 initial-bh-momentum1y = 0.1236938059674509982 initial-bh-momentum1z = 0 initial-bh-momentum2x = 0.003358311330506950042 initial-bh-momentum2y = -0.1236938059674509982 initial-bh-momentum2z = 0 initial-bh-spin1x = 0.1000000000000000056 initial-bh-spin1y = 0.2000000000000000111 initial-bh-spin1z = 0.2999999999999999889 initial-bh-spin2x = 0.01000000000000000021 initial-bh-spin2y = 0.02000000000000000042 initial-bh-spin2z = 0.02999999999999999889 initial-bh-puncture-adm-mass1 = 0.7117197159189734279 initial-bh-puncture-adm-mass2 = 0.5107035566228820267 }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/551> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #555: include header files for prototypes of getpid, sched_getaffinity etc.
by Einstein Toolkit 25 Sep '11

25 Sep '11

#555: include header files for prototypes of getpid, sched_getaffinity etc. -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: rhaas Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- three small patches that include header files or make prototypes in header files visible or avoid instantiating a template both explicitly and implicitly in Carpet. All three are required to get PGI to compile !Carpet/Hg (plus a change to loopcontrol.c which should not be required and seems to be due to a compiler deficiency when handling OpenMP). The first two actually make the code use fewer implicit declarations of functions, while the last one (#define NO_COMPLEX) [a] makes the code more systematic and [b] might actually avoid some implementation defined behaviour (though I am really not familiar enough with C++ templates to know). Unless there are objections I will apply these sometime near the end of the week (Friday or so). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/555> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #573: Handle derivative orders in WeylScal4 the same way as in McLachlan
by Einstein Toolkit 25 Sep '11

25 Sep '11

#573: Handle derivative orders in WeylScal4 the same way as in McLachlan -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/573> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #514: Regenerate code for WeylScal4
by Einstein Toolkit 25 Sep '11

25 Sep '11

#514: Regenerate code for WeylScal4 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- We need to regenerate the code for WeylScal4 with the current version of Kranc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/514> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #564: McLachlan: Make finite difference order and use of Jacobians selectable at runtime
by Einstein Toolkit 23 Sep '11

23 Sep '11

#564: McLachlan: Make finite difference order and use of Jacobians selectable at runtime -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- Currently, we generate separate !McLachlan thorns for different finite differencing orders and for single-patch and multi-patch. The attached patch makes use of a new feature in Kranc to enable all finite differencing orders in all thorns, as well as enabling multi-patch support in all thorns. These features can now be selected in all thorns via run- time parameters (fdOrder and jacobian_group). Each thorn defaults to the finite differencing order that it used before. This change should be entirely backwards-compatible so users don't need to change their parameter files or thornlists immediately. Use of any thorn other than ML_BSSN could be deprecated immediately, and people should start to transition to using only ML_BSSN. At some point in the future (after the next release), the other thorns will be dropped. I don't want to drop the other thorns immediately, as parameter files would have to be changed, and that makes comparing parameter files between runs very tedious. We need to decide whether we want to keep the _UPW variants. These cannot be used with vectorisation. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/564> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #572: Change scoping of TmunuBase parameter to allow parameter checking in other thorns
by Einstein Toolkit 23 Sep '11

23 Sep '11

#572: Change scoping of TmunuBase parameter to allow parameter checking in other thorns ------------------------------+--------------------------------------------- Reporter: filga@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: ------------------------------+--------------------------------------------- We would like to be able to check that support_old_CalcTmunu_mechanism is activated in order to ensure that we will be able to read the stress energy. However, the parameters in TmunuBase are all default scope, which is private. The attached patch fixed only the parameter we required. As other thorns may want to check other parameters, it might be sensible to change them all to restricted. Aaryn Tonita Filippo Galeazzi -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/572> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #574: Formaline: delete tarballs and C files after building object files
by Einstein Toolkit 23 Sep '11

23 Sep '11

#574: Formaline: delete tarballs and C files after building object files -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Formaline creates tarballs, converts them to C code, and then compiles them to object files. Once the object files are there, there is no point in keeping the corresponding tarball and C file, and they should be deleted to save disk space. This may be as simple as removing some .PRECIOUS statements from the Makefile. However, one has to ensure that deleting these files doesn't confuse make into believing that they have to be regenerated the next time. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/574> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #443: Output a stack backtrace on a fatal error in a simulation
by Einstein Toolkit 21 Sep '11

21 Sep '11

#443: Output a stack backtrace on a fatal error in a simulation -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- When a Cactus simulation aborts with a signal, it is often difficult to determine which part of the code led to the problem. The attached patch registers a signal handler on Carpet startup for signals 11 and 6 (segmentation fault and abort, e.g. from assert()) which outputs a stack backtrace from each process to a file, including demangling symbol names. It uses some low-level and possibly unofficial APIs, and is likely not completely portable. However, I have tested it on Mac OS (gcc) and Linux (intel) and it works in those places. Part of this code was contributed by Justin Luitjens at the Carpet developers' workshop in summer 2010. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/443> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #556: GetComponents doesn't use AUTH_URL for Mercurial
by Einstein Toolkit 21 Sep '11

21 Sep '11

#556: GetComponents doesn't use AUTH_URL for Mercurial ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: critical | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I am checking out Carpet (the Mercurial version) with the following CRL settings: !TARGET = $ARR !TYPE = hg !AUTH_URL = ssh://carpetmercurial@carpetcode.org/carpet !URL = http://www.carpetcode.org/hg/carpet I use this command: ~/Cvanilla/bin/GetComponents ~/Cvanilla/manifest/einsteintoolkit.th This uses the http url to check out Carpet, which is inconvenient since one can't push changes via this url. I expected GetComponents to use the authorized url unless I give the "-a" option. (This seems to work for git; McLachlan is checked out via AUTH_URL.) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/556> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #482: GetComponents chokes on thorn list using DOS EOL characters in !DEFINEs
by Einstein Toolkit 21 Sep '11

21 Sep '11

#482: GetComponents chokes on thorn list using DOS EOL characters in !DEFINEs ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: rhaas Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ the attached file uses DOS EOL conventions (ie. \r\n instead of the Unix typical \n) gives error messages: {{{ [rhaas3@phys44230 rhaas3]$ ./GetComponents --root dos --parallel cactus.th Unsuccessful stat on filename containing newline at ./GetComponents line 663. Unsuccessful stat on filename containing newline at ./GetComponents line 663. ----------------------------------------------------------------- Checking out module: Cactus from repository: http://svn.cactuscode.org/flesh/trunk into: dos as: . ----------------------------------------------------------------- Checking out module: CactusBase/Boundary from repository: http://svn.cactuscode.org/arrangements/CactusBase/Boundary/trunk into: dos/arrangements : No such file or directoryments Warning: Could not checkout module CactusBase/Boundary <some more of the same> ----------------------------------------------------------------- 1 components checked out. 0 components updated. Unable to process CactusBase/Boundary Unable to process CactusBase/CartGrid3D Unable to process CactusBase/CoordBase Unable to process CactusBase/InitBase Unable to process CactusBase/IOUtil Unable to process CactusBase/SymBase Unable to process CactusBase/Time Unable to process CactusNumerical/MoL Unable to process CactusBase/LocalInterp Unable to process CactusUtils/NaNChecker Unable to process CactusNumerical/Periodic Unable to process CactusUtils/Formaline Unable to process CactusNumerical/Slab Summary of Warnings: Could not checkout module CactusBase/Boundary Could not checkout module CactusBase/CartGrid3D Could not checkout module CactusBase/CoordBase Could not checkout module CactusBase/InitBase Could not checkout module CactusBase/IOUtil Could not checkout module CactusBase/SymBase Could not checkout module CactusBase/Time Could not checkout module CactusNumerical/MoL Could not checkout module CactusBase/LocalInterp Could not checkout module CactusUtils/NaNChecker Could not checkout module CactusNumerical/Periodic Could not checkout module CactusUtils/Formaline Could not checkout module CactusNumerical/Slab Time Elapsed: 0 minutes, 8 seconds }}} This is due to a \r which becomes part of the ARRANGEMENTS !DEFINE. A simple solution might be for GetComponents to remove whitespace from end of input lines via a: {{{ diff --git a/GetComponents b/GetComponents index 133487e..5e801f3 100755 --- a/GetComponents +++ b/GetComponents @@ -305,6 +305,9 @@ sub parse_list { my @lines = <$COMPONENT_LIST>; close($COMPONENT_LIST); + # convert CRNL and CR to newline (for lists generated by windows and macs) + map s/(\r\n|\r)/\n/gm, @lines; + # handle includes my $i = -1; foreach my $line (@lines) { }}} Note that his renders the CRtoNL regex on $file below useless (I am also not sure to what extent we need $orig_file to have the native EOL character). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/482> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac