Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1186: Provide a version of CCTK_WARN which never returns
by Einstein Toolkit 25 Feb '13

25 Feb '13

#1186: Provide a version of CCTK_WARN which never returns -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- CCTK_WARN(0,...) always causes a fatal abort, but the compiler does not know this. Hence, it incorrectly warns that variables might be used without being set because it doesn't know that the only path that doesn't set them terminates the program. I propose introducing a new function CCTK_WARN_ABORT(...) which calls CCTK_WARN(0,...) and is declared with the attribute noreturn (http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function- Attributes.html) so that the compiler knows that it can never return, and does not make incorrect conclusions when computing variable dependencies (CCTK_Abort is already defined without an error message). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1186> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1255: change default of IOUtil::out_dir from "." to "$parfile"
by Einstein Toolkit 25 Feb '13

25 Feb '13

#1255: change default of IOUtil::out_dir from "." to "$parfile" -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently the default output directory for Cactus output is ".", something that is hardly every used by anybody. We should strive to have parameter defaults that work in most circumstances and that are used by most people. "." is save, but not at all the most wanted choice. "$parfile" is another sensible choice, should be as save as "." and is used by more (>0) users than their default. Thus, I propose to test to change the default. Before getting into this (unknown) amount of work, let me use this ticket to ask for objections first. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1255> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

Re: [ET Trac] [Einstein Toolkit] #30: Implement a "get" command
by Einstein Toolkit 22 Feb '13

22 Feb '13

1 0

Re: [ET Trac] [Einstein Toolkit] #30: Implement a "get" command
by Einstein Toolkit 22 Feb '13

22 Feb '13

1 0

Re: [ET Trac] [Einstein Toolkit] #30: Implement a "get" command
by Einstein Toolkit 22 Feb '13

22 Feb '13

1 0

Re: [ET Trac] [Einstein Toolkit] #30: Implement a "get" command
by Einstein Toolkit 22 Feb '13

22 Feb '13

1 0

Re: [ET Trac] [Einstein Toolkit] #30: Implement a "get" command
by Einstein Toolkit 22 Feb '13

22 Feb '13

1 0

Re: [ET Trac] [Einstein Toolkit] #30: Implement a "get" command
by Einstein Toolkit 22 Feb '13

22 Feb '13

1 0

Re: [ET Trac] [Einstein Toolkit] #30: Implement a "get" command
by Einstein Toolkit 22 Feb '13

22 Feb '13

#30: Implement a "get" command --------------------------+------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Comment (by hinder): We will need some way to ensure that the retrieved data is in a consistent state. Truncated ASCII files can be dealt with, though this is not ideal, but partially-written HDF5 files cannot. This can be a serious problem if several HDF5 files are being synced, as after each sync, there can be a high probability that at least one of them is incompletely written. Some options: 1. SimFactory (on the remote machine) writes a control file (either into the simulation or somewhere else) which indicates to the simulation that it should not open any new files for writing, and once it has closed any currently open file as part of normal operation, it should record this information in the control file, continue running, and only write new files once the control file tells it to. This has the disadvantage of locking the entire simulation for the duration of the transfer of the active restart. For slow data transfers, this could be a significant amount of time. This approach has the disadvantage that the different files will not be in a consistent state; e.g. one output file may have the current iteration but another may not. 2. Before writing a file, Cactus would move it to a new location (file.tmp), and only move it back when it was fully written. SimFactory would not sync tmp files. Any files which had been renamed to *.tmp in the first pass would then be synced in a separate pass using their original names, if they exist. Repeat until all files are synced. This solution also does not maintain a consistent state across multiple files. This does not require write access to the simulation directory, so could also be used by collaborators who do not own the simulation. 3. Similar to (1), but only performed at the end of an iteration. SimFactory would indicate to Cactus to pause the simulation at the end of the current iteration, when all files are presumably valid on disk. Cactus would indicate that the simulation had paused in a control file, and SimFactory would then transfer the data, and unpause the simulation when it was finished. This would guarantee that the synced data was in a consistent state. We might want to have some mechanism to ensure that simulations do not remain paused forever, perhaps by requiring simfactory to update the control file periodically if it is still syncing. All of the above apply only to the active restart. I think (3) is the simplest and most robust. It is also the most expensive in SUs. The control file location could be customisable, and placed somewhere that all collaborators have write access. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/30#comment:1> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1257: known_architectures/linux doesn't deal with non-standard gcc version output
by Einstein Toolkit 21 Feb '13

21 Feb '13

#1257: known_architectures/linux doesn't deal with non-standard gcc version output --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2013_05 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently, known_architectures/linux only looks at the first line of '$F77 --version' to determine the version of a gnu-type fortran compiler. However, on bluewaters this returns {{{ /opt/cray/xt-asyncpe/5.16/bin/ftn: INFO: Compiling with CRAYPE_COMPILE_TARGET=native. GNU Fortran (GCC) 4.7.2 20120920 (Cray Inc.) Copyright (C) 2012 Free Software Foundation, Inc. }}} The information the script is actually interested in is on the second line, not the first. Thus, I propose the attached patch (grepping for "GNU" before choosing the first line). I didn't find a problem with this patch on other machines, but there might be in case $F77 --version does not contain GNU in the line with the version. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1257> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac