Trac May 2014

trac@lists.einsteintoolkit.org

2 participants
138 discussions

[Einstein Toolkit] #1210: CarpetIOASCII should not write column names info each iteration
by Einstein Toolkit 01 Jun '14

01 Jun '14

#1210: CarpetIOASCII should not write column names info each iteration --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- Currently, CarpetIOASCII writes the column names header each iteration, leading to bloated output - easily double the size of what should suffice. Once after file creation would be much better. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1210> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1620: TimerReport doesn't scale very well.
by Einstein Toolkit 28 May '14

28 May '14

#1620: TimerReport doesn't scale very well. ---------------------+------------------------------------------------------ Reporter: bmundim | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ During some scaling tests of a unigrid domain using only MPI (no OpenMP) on Supermuc with Noether release, I noticed that the routine doing the TimerReport routine scales very poorly. I had set the following relevant parameters: {{{ Cactus::cctk_itlast = 256 TimerReport::out_every = 128 TimerReport::output_all_timers_readable = "yes" TimerReport::output_schedule_timers = "no" TimerReport::n_top_timers = 200 Carpet::output_timer_tree_every = 128 Carpet::output_initialise_timer_tree = "yes" Carpet::sync_barriers = "yes" }}} With 144 MPI processes the timer routine didn't take much time of the simulation: {{{ INFO (TimerReport): Top timers at iteration 256 time 29.0133 ====================================================================== % Time/s Min/s Max/s Timer (gettimeofday) ====================================================================== 100.0 6172.83 6172.82 6172.92 meta mode ... 0.0 1.24 1.21 2.34 [0176] TimerReport: zzz_TimerReport_Output in CCTK_ANALYSIS ... 0.0 0.96 0.93 1.81 main/Evolve/CallAnalysis/CCTK_ANALYSIS/CallFunction/thorns/zzz_TimerReport_Output ... }}} While with 2304 MPI jobs, it clearly shows how bad it scales: {{{ INFO (TimerReport): Top timers at iteration 256 time 29.0133 ====================================================================== % Time/s Min/s Max/s Timer (gettimeofday) ====================================================================== 100.0 618.300 618.288 618.316 meta mode ... 8.5 52.462 52.372 79.462 [0176] TimerReport: zzz_TimerReport_Output in CCTK_ANALYSIS ... 6.7 41.451 41.435 61.203 main/Evolve/CallAnalysis/CCTK_ANALYSIS/CallFunction/thorns/zzz_TimerReport_Output ... }}} Two things caught my attention here. One was obviously how bad zzz_TimerReport is scaling as the number of MPI processes increase. The second was the inconsistency between the timers "[0176] TimerReport:..." and "main/Evolve/...". Why do they show different times for the same function? Anyways, it might not be overall important but I would like to leave it reported here about this issue. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1620> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1625: Carpet should check that the grid structure is the same on all processes
by Einstein Toolkit 27 May '14

27 May '14

#1625: Carpet should check that the grid structure is the same on all processes -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- Carpet should check that the grid structure is the same on all processes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1625> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1399: add evolution method "stationary" to ADMBase
by Einstein Toolkit 27 May '14

27 May '14

#1399: add evolution method "stationary" to ADMBase -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: ADMBase | -----------------------------------+---------------------------------------- This method is similar to "static" in that it can be used for Cowling runs, it differs from "static" in that it schedules the initial data routine after any grid changes and does not apply boundary conditions or SYNC calls. It can thus be used if one can compute the required metric/shift/lapse easily in a pointwise manner and would like to have exact (non-prolongated) data in the buffer zones. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1399> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1548: stdout redirection in multithreading scenario
by Einstein Toolkit 22 May '14

22 May '14

#1548: stdout redirection in multithreading scenario ---------------------------------+------------------------------------------ Reporter: gzheng@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: stdout redirection | ---------------------------------+------------------------------------------ Current stdout redirection scheme implemented in CommandLine.c:CCTKi_CommandLineFinished() (which redirects stdout to a file or /dev/null based on myproc) does not work on multithreaded MPI (e.g AMPI), because it redirects all output (from all threads in a process). That is, all MPI ranks in a process will be mistakenly directly to one file, or if redirecting to /dev/null, there will be simply no output. It may be possible to implement a cctk_printf function, which checks myproc and manage the output for each thread. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1548> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1302: Reduce time spent in deciding not to do output.
by Einstein Toolkit 21 May '14

21 May '14

#1302: Reduce time spent in deciding not to do output. --------------------------------------+------------------------------------- Reporter: diener | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: performance optimization | --------------------------------------+------------------------------------- I noticed, during some scaling tests, that for my code a significant amount of time was spent by CarpetIOASCII, even though I only had it activated and didn't actually request any output. The reason is that in order to figure out whether to do output or not, there is a loop over all grid variables and a routine (TimeToOutput) is called. In this routine there is a check if the out_dir and out_vars parameters have been steered and if so update some internal data structures. It should be sufficient to do this before entering the loop over grid variables. The same issue is present in CarpetIOScalar and CarpetIOHDF5. The attached patches for CarpetIOASCII, CarpetIOScalar and CarpetIOHDF5 moves this check outside of the loop over grid variables and in addition bypasses the loop completely if the out_vars parameter string is the empty string. Note that the code where I noticed this problem uses large vectors of 1D grid arrays, and it turns out that Cactus counts each vector element as a distinct grid variables and the length of the loop over grid variables in my case was close to 100.000, which might explain why nobody has noticed this before. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1302> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1554: Want to define constants in parameter files
by Einstein Toolkit 21 May '14

21 May '14

#1554: Want to define constants in parameter files -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- I would like to define constants in parameter files, such as: {{{ $rho = 1 grid::dx = 1.0/$rho IOASCII::out_every = 10*$rho }}} The expansion of expressions is already implemented, but is limited to parameters. Being able to define constants would be very cool. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1554> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 34

[Einstein Toolkit] #1597: use gsissh when connecting to bluewaters
by Einstein Toolkit 20 May '14

20 May '14

#1597: use gsissh when connecting to bluewaters -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- the attached patch copies functionality from kraken.ini to use in bluewaters.ini and to have it use a myproxy instance to avoid having to enter the password each time one connects to bluewaters. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1597> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1468: Building a configuration with just the MPI thorn fails
by Einstein Toolkit 20 May '14

20 May '14

#1468: Building a configuration with just the MPI thorn fails ----------------------+----------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- If I build a Cactus configuration with a thornlist containing just the MPI thorn (i.e no driver or any other thorns), the compilation fails with {{{ COMPILING /Users/ian/Cactus/EinsteinToolkit/src/comm/CactusDefaultComm.c In file included from /Users/ian/Cactus/EinsteinToolkit/configs/mpitest/build/Cactus/comm/CactusDefaultComm.c:33: /opt/local/include/openmpi/mpi.h:367: error: wrong number of arguments specified for ‘__deprecated__’ attribute }}} Building the flesh without the MPI thorn works OK. This is on Mac OS with MPI from MacPorts. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1468> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1616: Carpet VisIt plugin should use VisIt HDF5 library
by Einstein Toolkit 19 May '14

19 May '14

#1616: Carpet VisIt plugin should use VisIt HDF5 library ---------------------------------+------------------------------------------ Reporter: dradice@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ---------------------------------+------------------------------------------ The Carpet HDF5 VisIt plugin should be linked agains the HDF5 library shipped with VisIt. VisIt already provides a way to do this automatically. Currently the include and library paths are manually set in the plugin. I am attaching a patch that fixes that. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1616> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2014