Trac December 2013

trac@lists.einsteintoolkit.org

1 participants
146 discussions

[Einstein Toolkit] #1291: Boundary does not check for storage
by Einstein Toolkit 13 Jan '14

13 Jan '14

#1291: Boundary does not check for storage -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I accidentally selected a variable for a flat boundary condition (with thorn Boundary) without storage. This led to a segfault. Instead, thorn Boundary should output an error message or a warning. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1291> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1469: Invalid integer parameters cause a confusing error message
by Einstein Toolkit 06 Jan '14

06 Jan '14

#1469: Invalid integer parameters cause a confusing error message --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- If an integer-valued parameter is assigned a value such as 100000000000000000000000 which is too large to fit into an integer, the Piraha parameter parser interprets it as a real and complains {{{ (line 15 of sim.par): -> Parameter type mismatch INT != REAL }}} This message is not very helpful. A better error message might be: {{{ (line 15 of sim.par): -> Parameter MyThorn::mypar cannot be set to the value 10000000000000000000 as this is not a valid INT value }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1469> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1499: Error in synchronisation after restriction
by Einstein Toolkit 06 Jan '14

06 Jan '14

#1499: Error in synchronisation after restriction --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- Carpet does not currently restrict into ghost points, and it does not synchronise after restricting, as synchronisation is expected to be performed by user thorns in MoL_PostStep at the same time as application of boundary conditions, and MoL_PostStep is scheduled by MoL in CCTK_POSTRESTRICT, which occurs after restriction. Unfortunately, CCTK_POSTRESTRICT is traversed in the order coarse to fine, whereas restriction happens fine to coarse, so the synchronisation applied by the user thorns does not occur in the correct order. This leads to incorrect data on the coarse grid. I noticed this when comparing output in 3D between identical simulations run on different numbers of processes. The simple fix is to synchronise after restricting on each level; this ensures that the result is correct, but introduces a performance penalty due to the additional sync. One optimisation is possible. Carpet currently does not restrict into ghost zones, leading to the requirement of a synchronisation after restriction. Carpet can be made to restrict into ghost zones, but only if the restriction operator has a single-point stencil (e.g. point-copying used in vertex-centered mesh refinement). If this is the case, the sync after restriction is no longer necessary. The branch [[http://git.carpetcode.org/carpet.git/log/refs/heads/master..refs/heads/ianh… | ianhinder/restrictsync]] implements these changes. (aside: the CSS styling on git.carpetcode.org has been broken for a while) 1. Carpet: Add restriction sync test Test data generated on 1 process. Test fails on 2 processes due to lack of synchronisation in Carpet after restriction. 2. Carpet: Sync after restriction on each level Synchronising in POSTRESTRICT (e.g. in MoL_PostStep) is not sufficient, as there it happens coarse-to-fine, whereas it needs to happen fine-to-coarse, like restriction. This introduces an additional sync of all restricted variables, which will have a performance impact. The coarse grid was, however, incorrect before. test_restrict_sync now passes on 1, 2 and 4 processes. It fails on 8 processes due to an additional blank line in the output which the test system does not tolerate. 3. Carpet, CarpetLib: Restrict into ghost zones and skip sync after restrict if not using higher order restriction test_restrict_sync still passes on 1 and 2 processes Notes: * We could enable (3) via a parameter since it is an optimisation. However, Erik believes the optimisation is always correct, and all the tests continue to pass, so I am tentatively proposing that no additional parameter is required. * Can we make this sort of problem easier to detect? e.g. by poisoning the ghost points which are not set by restriction? When relying on user thorns to do something, can we poison the corresponding points first? Thanks to Erik for helping to diagnose the problem and suggesting possible fixes. ET test results unchanged on 1 and 2 processes. Comments on the commits? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1499> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #1369: Error link doesn't work on Mac
by Einstein Toolkit 06 Jan '14

06 Jan '14

#1369: Error link doesn't work on Mac ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: sbrandt Type: defect | Status: new Priority: major | Milestone: Cactus_4.3.0 Component: Mojave | Version: Keywords: | ---------------------+------------------------------------------------------ Error link doesn't work on Mac -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1369> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1498: GRHydro_InitData: add parameter for pressure term in poloidal field configuration
by Einstein Toolkit 05 Jan '14

05 Jan '14

#1498: GRHydro_InitData: add parameter for pressure term in poloidal field configuration -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The attached patch adds a parameter for an exponent of the pressure term in a poloidal magnetic field configuration. The default is set to 1, maintaining current status. The testsuite using this still passes after applying this patch, with identical files. Once this patch has been applied, there will be a second testsuite added setting the new parameter to something else than the default (but otherwise similar to the now existing one). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1498> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1507: Repository tags for the ET_2013_10 release have not been created
by Einstein Toolkit 27 Dec '13

27 Dec '13

#1507: Repository tags for the ET_2013_10 release have not been created --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Each release of the ET should have tags in the repositories identifying the release, as well as any minor version increments due to backports. We have tags for ET_2013_05_v0 but not for ET_2013_11_v0. It would also be good to create new tags based on the branch every so often after fixes have been backported, so that it is possible to easily identify a specific version of the toolkit, e.g. ET_2013_11_v1. Frank is going to create ET_2013_10_v0 tags. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1507> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1510: OpenSSL fails to build on fedora core 20
by Einstein Toolkit 25 Dec '13

25 Dec '13

#1510: OpenSSL fails to build on fedora core 20 -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: OpenSSL | -----------------------------------+---------------------------------------- we get an error: {{{ cms.pod around line 457: Expected text after =item, not a number cms.pod around line 461: Expected text after =item, not a number cms.pod around line 465: Expected text after =item, not a number cms.pod around line 470: Expected text after =item, not a number cms.pod around line 474: Expected text after =item, not a number }}} which seems to be identical to the error observed by the Arch Linux maintainers: https://bugs.archlinux.org/task/35868 their fix (see comments below) is here https://bugs.archlinux.org/task/35868?getfile=10648 Ok to include in OpenSSL or should we require Fedora users to install OpenSSL from the distro packages? It builds fine eg on Ubuntu 13.04 even without the patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1510> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1508: abort if boundary widht is very wide (>100 points)
by Einstein Toolkit 22 Dec '13

22 Dec '13

#1508: abort if boundary widht is very wide (>100 points) -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: Boundary | -------------------------+-------------------------------------------------- Currently if a user schedules the routine calling Boundary_RegisterGroupForBC in LEVEL mode (which is the correct mode), cctk_nghostzones is undefined and Carpet fills it with the deadbeef value (666). Passing 666 to Boundary_RegisterGroupForBC leads to silently incorrect results as it often prevents the BC from being applied at all (there is a check in many boundary routines that returns if the domain is too small, presumably to support 1 point wide 1d domains). The attached patch checks the boundary width requested and aborts if the width is larger than 100. This is the same threshold that the symmetry thorns already use to abort a run. This prevents a user error (seen it twice so far) and should not as far as I can tell affect any correct code (unless we ever actually encounter a boundary wider than 100 points in which case we are in trouble anyway). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1508> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1367: Mojave commands don't work with symlinks
by Einstein Toolkit 20 Dec '13

20 Dec '13

#1367: Mojave commands don't work with symlinks ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: sbrandt Type: defect | Status: new Priority: major | Milestone: Cactus_4.3.0 Component: Mojave | Version: Keywords: | ---------------------+------------------------------------------------------ Mojave commands don't work with symlinks -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1367> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1504: MoL RK87 non-functional
by Einstein Toolkit 20 Dec '13

20 Dec '13

#1504: MoL RK87 non-functional -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: MoL | -----------------------------------+---------------------------------------- currently (Noether release and trunk, since rev 190) MoL's RK87.c file contains a line (line 234): {{{ CCTK_WARN(0, "Peter has been too lazy to write the RK87 routine " "out for array variables. Better send him an email..."); }}} which unconditionally aborts the run whenever RK87 is used, even when used for grid functions and not grid arrays. The fix is obviously to check MoLNumEvolvedArrayVariables before aborting: {{{ if (MoLNumEvolvedArrayVariables > 0 || MoLNumEvolvedComplexArrayVariables > 0) { CCTK_WARN(0, "Peter has been too lazy to write the RK87 routine " "out for array variables. Better send him an email..."); } }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1504> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2013