Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

Re: [ET Trac] [Einstein Toolkit] #52: Ensure consistency between configurations on different systems
by Einstein Toolkit 25 Aug '11

25 Aug '11

#52: Ensure consistency between configurations on different systems --------------------------+------------------------------------------------- Reporter: anonymous | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Comment (by eschnett): One of Simfactory's goals is to remove the difference between different machines. Ideally, one would just "submit" a simulation, and some semi- automated mechanism would figure out where to submit (or would submit multiple times and keep only the first job that then starts), or would allow easily to restart on a different system, allows monitoring all current simulations independent of where they are running, etc. I have two thorn lists (development and production) in two different source trees, and use the same thorn lists on all systems. If a thorn doesn't work on a particular system this is noted in the MDB. I almost never specify a configuration name manually. If the default changed from "sim" to the thorn list name, I would not be bothered much. In a way, this ticket is already implemented. Simfactory distributes e.g. the manifest directory, and one can set a default thorn list in defs.local.ini. Are there people who regularly build multiple configurations in the same source tree? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/52#comment:2> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Re: [ET Trac] [Einstein Toolkit] #52: Ensure consistency between configurations on different systems
by Einstein Toolkit 25 Aug '11

25 Aug '11

#52: Ensure consistency between configurations on different systems --------------------------+------------------------------------------------- Reporter: anonymous | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Comment (by knarf): I don't think this is a good idea. In part, because it goes against my usual practice. I usually call configurations simply 'sim' out of convenience and often have several complete checkouts for different configurations - often because I do have different versions of the same thorn, or would like to update some thorns for one configuration but not another. I would not be interested in a simulation name similar to the thornlist name. Just for the record: yes, I do usually use the same thornlist for the same checkout and configuration name. I just don't see the need to enforce that. This ticket is already quite old. If there is no other opinion within a week or so, I will probably close it - because it is also not known who actually submitted it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/52#comment:1> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #516: Enable Vectorisation in McLachlan
by Einstein Toolkit 25 Aug '11

25 Aug '11

#516: Enable Vectorisation in McLachlan -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Kranc generated thorns now have support for optimisation through vectorisation. They just need the option UseVectors -> True to be set when creating the thorn. The attached patches enable this for the BSSN thorns in McLachlan. I have tested that this gives a significant performance increase (close to 2x in the right-hand-sides in the cases I tried) and also that it agrees to within what would be expected given roundoff differences with the results of a BBH simulation with vectorisation disabled. Additionally, the testsuites still pass with this patch applied. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/516> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #490: McLachlan test case failing due to ADMBase variable differences
by Einstein Toolkit 25 Aug '11

25 Aug '11

#490: McLachlan test case failing due to ADMBase variable differences -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The McLachlan test ML_BSSN_sgw3d has been failing since 03-Aug-2011. The only tested variable which is showing differences is kxx, but the differences appear to be significantly larger than roundoff: kxx.x.asc: substantial differences significant differences on 16 (out of 36) lines maximum absolute difference in column 13 is 0.000822901437894541 maximum relative difference in column 13 is 0.0560528644051835 (insignificant differences on 16 lines) This coincides with the following commit: commit 3ba8a55ae2578cb6dc06f0ec8b81f86b3a2654ac Author: Erik Schnetter <schnetter(a)cct.lsu.edu> Date: Tue Aug 2 20:37:19 2011 -0400 Correct schedule, in particular for checkpoint/recovery Do not mark ADMBase variables for non-checkpointing if they have multiple timelevels. (Variables with multiple timelevels must always be checkpointed, because the past timelevels cannot be regenerated after recovery.) Finally remove all perl post-processing of the auto-generated code; instead, use proper Kranc mechanisms. Schedule the ADM constraints and ADM quantities after MoL_PostStep, since this is where the ADMBase variables are set. Schedule enforcing the BSSN constraints in the new schedule group MoL_PostStepModify, since they should not be enforced after recovery. (This would lead to inconsistencies at floating-point round-off level.) Regenerate all thorns. and the other commits made to Cactus at the same time as explained in this email: http://cactuscode.org/pipermail/users/2011-July/002872.html Attached is a diff which shows what changed between the test passing and failing. Since this test does not deal with checkpointing or recovery, I don't understand why kxx should change so drastically. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/490> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #438: Allow a configuration.ccl for the flesh
by Einstein Toolkit 25 Aug '11

25 Aug '11

#438: Allow a configuration.ccl for the flesh ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- The mechanism in Cactus that handles configuration.ccl files currently cannot handle a configuration.ccl for the flesh. The enclosed patch corrects this. This is a prerequisite for moving the MPI configuration code out of the flesh and into a thorn (as we already did for all other external libraries). The flesh will need to know whether MPI is used or not, since MPI needs to be initialized before the parameter file is read. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/438> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #207: Cactus should have an option to store the mpirun command needed to run test cases
by Einstein Toolkit 24 Aug '11

24 Aug '11

#207: Cactus should have an option to store the mpirun command needed to run test cases -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus should be able to remember from configuration the mpirun command syntax needed to run test cases. This would simplify running test cases, which could then probably even be automated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/207> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #529: IOJpeg warnings when cctk_gsh[2]==1
by Einstein Toolkit 20 Aug '11

20 Aug '11

#529: IOJpeg warnings when cctk_gsh[2]==1 -----------------------------------+---------------------------------------- Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- IOJpeg works perfectly well when one of the dimensions of a 3D grid function is one, but it issues annoying warning messages. This patch turns them off. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/529> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #513: Make signbit in Vectors work on more architectures
by Einstein Toolkit 19 Aug '11

19 Aug '11

#513: Make signbit in Vectors work on more architectures -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Several C++ compilers cannot handle std::signbit. There is also a namespace problem when using the same identifier Vectors_SGN for different precisions (real*4 and real*8). In addition, kifpos is implemented incorrectly on several architectures. The attached patch corrects these. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/513> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #468: CCTK_GFINDEX3D should check indices when CCTK_DEBUG is defined
by Einstein Toolkit 19 Aug '11

19 Aug '11

#468: CCTK_GFINDEX3D should check indices when CCTK_DEBUG is defined ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- It should. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/468> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #524: Improve convergence order in QuasiLocalMeasures
by Einstein Toolkit 19 Aug '11

19 Aug '11

#524: Improve convergence order in QuasiLocalMeasures -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Thorn QuasiLocalMeasures has several operations that are only second order accurate, in particular two different integrations over the Killing vector field in the surface. These use RK2 at the moment, and should be improved to using RK4. With these changes, QLM should become fourth order accurate. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/524> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

← Newer
1
...
12
13
14
15
16
17
18
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011