Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #853: Incorrect tensor parity in WeylScal4
by Einstein Toolkit 03 May '12

03 May '12

#853: Incorrect tensor parity in WeylScal4 ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | ---------------------------+------------------------------------------------ Some time ago, I discovered what appears to be a bug in the tensor parities in WeylScal4. I seem to have forgotten to report it at the time and my memory is now a bit hazy, but as far as I recall the parity of Psi3r is incorrect and should be {1,1,-1}, the same as Psi1r. This makes sense if you think of the "I" invariant which is a scalar and which contains the term: -4 Psi1r*Psi3r. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/853> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #857: removing configs/NAME/config-info leaves configuation in problematic state
by Einstein Toolkit 03 May '12

03 May '12

#857: removing configs/NAME/config-info leaves configuation in problematic state --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- After removing configs/NAME/config-info and trying to reconfig I get the following: $ make sim-reconfig Cactus - version: 4.0.1 Error reconfiguring 'sim': configuration is incomplete. Use 'make sim-reconfig' to configure the configuration. make: *** [sim-reconfig] Error 2 $ make sim-reconfig Cactus - version: 4.0.1 Error reconfiguring 'sim': configuration is incomplete. Use 'make sim-reconfig' to configure the configuration. make: *** [sim-reconfig] Error 2 It should not ask me to do what I just did, especially not if this doesn't work. :) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/857> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #856: simfactory silently ingores option lists if the file name is wrong
by Einstein Toolkit 03 May '12

03 May '12

#856: simfactory silently ingores option lists if the file name is wrong ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Specifying a non-existent file in the optionlist entry in a machine.ini file does not trigger an error, instead simfactory (with --verbose) says: {{{ Info: optionlist is: None Warning: no option list specified, using blank option list }}} then happily continues the build process until it dies because it could not find MPI for Carpet (typically). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/856> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #851: ReflectionSymmetry Interpolation Errors and WeylScal4
by Einstein Toolkit 03 May '12

03 May '12

#851: ReflectionSymmetry Interpolation Errors and WeylScal4 --------------------+------------------------------------------------------- Reporter: tbode | Owner: tbode Type: defect | Status: new Priority: major | Milestone: ET_2012_05 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- There is an inconsistency in ReflectionSymmetry on whether a scalar can have a tensor parity tag that isn't unity (pseudoscalars). In ReflectionSymmetry's apply.c, a scalar GF's tensorparity flag is taken into account, while in interpolation this is ignored. In the ET Toolkit, this only effects those using the ET version of WeylScal4 since only Psi4i, Psi2i, and Psi0i have all been registered as scalars with tensorparity=-1. When interpolating, e.g. Psi4, onto a sphere for mode decomposition, the interpolated quantities have sign errors in Psi4i and give erroneous gravitational wave modes. This problem applies to both Maxwell release and current development branch. Symptoms reported to me by Jim Healy. I would suggest backporting the resulting fix to Maxwell. Either ReflectionSymmetry's interpolation has to allow for tensorparity=-1, or apply.c's acceptance of tensorparity=-1 should be removed and WeylScal4's GFs reverted to manually specified parities. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/851> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #686: Handle requirements recursively
by Einstein Toolkit 02 May '12

02 May '12

#686: Handle requirements recursively ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- [This patch includes CreateConfigurationBindings-cleanup.patch (#685): once CreateConfigurationBindings-cleanup.patch has been applied, the diffs in this patch will be much reduced in size.] Handle requirements recursively: If A requires B, and B requires C, then A also requires C. This is necessary e.g. for include directories: If A includes a file from B, which in turn includes a file from C, then C's include directory must be in the search path of A. Complete implementation of INCLUDE directives when parsing configuration.ccl scripts. Add more stringent checking of capability names: Only identifiers are allowed. This prevents the capability ":" from appearing when syntax errors in configuration.ccl files are not detected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/686> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #843: Don't autogenerate _O2 McLachlan thorns
by Einstein Toolkit 02 May '12

02 May '12

#843: Don't autogenerate _O2 McLachlan thorns -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Since the discretization order specific thorns (_O2 etc.) are not part of the Einstein Toolkit any more, we should also stop autogenerating them. This will make regenerating them faster. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/843> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #854: WeylScal4 should have multi-process test cases
by Einstein Toolkit 02 May '12

02 May '12

#854: WeylScal4 should have multi-process test cases -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- WeylScal4 currently has two tests, both of which run on a single process only. To test parallelisation, I propose that these be changed to run on two processes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/854> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #852: Carpet overlap zone tests fail on 1 process
by Einstein Toolkit 02 May '12

02 May '12

#852: Carpet overlap zone tests fail on 1 process --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- Tests Carpet/no-overlap and Carpet/overlap fail on one process but pass on 2. http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/ Probably the test uses grid function output and needs to be restricted to one process via test.ccl. Or maybe this would be a good opportunity to test whether CarpetIOASCII is really capable of writing processor- independent output! -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/852> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #713: Implement "Conformal Covariant Z4" formulation in McLachlan
by Einstein Toolkit 02 May '12

02 May '12

#713: Implement "Conformal Covariant Z4" formulation in McLachlan -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The [http://arxiv.org/abs/1106.2254 conformal covariant Z4] formulation is a variant of the Z4 system which can be implemented as a modification to existing BSSN codes through the addition of some terms and a single evolved grid function. Dana Alic implemented and tested this in McLachlan. I have created a "CCZ4" branch and committed her work, then merged some recent changes which were committed to the master branch since the version she based her code off of. It would be nice to merge this branch back into master, but I am unsure how to proceed. Two options are: 1. Create a separate Kranc script for the CCZ4 system. This has the advantage of keeping the existing code tidier and easier to read. 2. Keep a single Kranc script and add a parameter to select which formulation to use. This may make it easier to maintain both versions as there is a very large overlap between the two. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/713> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #847: Support OpenCL source code
by Einstein Toolkit 01 May '12

01 May '12

#847: Support OpenCL source code -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- OpenCL source code needs to be compiled at run time, and thus needs to be passed as string to the OpenCL run-time library. This makes writing OpenCL source code inconvenient. This patch adds *.cl as supported file type to Cactus. *.cl files are transformed into globally visible strings, with a name consisting of the thorn name and file name. These strings can then be easily used at run time to build and run OpenCL code. Since *.cl files are converted to strings (and are not OpenCL-compiled at build time), there are no CL* options specifying compiler type, compiler flags etc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/847> 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