Trac January 2014

trac@lists.einsteintoolkit.org

1 participants
145 discussions

[Einstein Toolkit] #1513: git complains about old repo configuration
by Einstein Toolkit 07 Jan '14

07 Jan '14

#1513: git complains about old repo configuration --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- On git push I see some warnings every time (see below). A short google search suggested that this is a repository configuration problem (on the remote side) {{{ remote: WARNING: git repo-config is deprecated in favor of git config. remote: WARNING: git repo-config is deprecated in favor of git config. remote: WARNING: git repo-config is deprecated in favor of git config. remote: WARNING: git repo-config is deprecated in favor of git config. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1513> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2014