Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #522: Improve consistency and performance of sync/build/create
by Einstein Toolkit 19 Aug '11

19 Aug '11

#522: Improve consistency and performance of sync/build/create -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- One of the design goals of SimFactory is to make it very difficult for a user to make mistakes or end up with inconsistent results. Currently, if a user modifies a source file and submits a simulation without remembering to rebuild the configuration, the old version of the configuration will be used. SimFactory could scan all the source files which would be used for a build and warn the user if there are new source files. Optionally it could also rebuild the configuration automatically. This check might be better implemented in Cactus, which in principle has the dependency information already. It is functionally equivalent to performing a build before every create, so maybe the best approach would be to make the Cactus build process much faster in the case where no files have been modified. This may not be possible. A related idea is to ensure that remote configurations are synced before being built, and parameter files are synced before simulations are created. One could record the time of the last successful sync (separately of the source tree and the parameter files) to each machine, and look for files which have been modified since that time. If there are such files, a sync could be initiated, or the user warned. Statting files on a laptop should be very fast. Statting files on Kraken can take minutes or hours. This information could also be used to restrict the list of files synced, to avoid having to stat every file in the source tree on the remote system. This assumes that the only modifications of the source tree on the remote system are due to simfactory on the local system. For me, this is the case 99.999% of the time. I attach a script that I wrote to interact conveniently with remote systems. It performs a sync of either the source tree or the parameter files depending on the simfactory command you want to run. It allows you to use the syntax <machine> <command> <args> instead of sim --remote <machine> <command> <args> e.g. damiana list-simulations The script should be somewhere on your path, and symlinks named after machines should be created pointing to it. For example, cp machine .../bin chmod u+x .../bin/sim/machine cd .../bin ln -s machine datura ln -s machine damiana ln -s machine kraken cd ~/Cactus datura sync datura create-submit ... datura build -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/522> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #518: Interact with TRAC by email
by Einstein Toolkit 18 Aug '11

18 Aug '11

#518: Interact with TRAC by email ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- I always read trac tickets by email, often when not connected to the internet. It would be extremely useful to be able to reply to tickets by email. I found this: https://subtrac.sara.nl/oss/email2trac. Can we inatall it and try it out? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/518> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #333: The ADMBase variables are not initialized after regridding
by Einstein Toolkit 17 Aug '11

17 Aug '11

#333: The ADMBase variables are not initialized after regridding --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- Ian Hawke: The point is that no BCs are applied to ADMBase variables, so they're never SYNC'd, so never initialized on refined grids. Ian sent a patch which I extended at bit and attached to this ticket. Please review. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/333> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #366: New thorn TestPar
by Einstein Toolkit 17 Aug '11

17 Aug '11

#366: New thorn TestPar -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I enclose a new thorn: Test the parameter file parser in Cactus, in particular multi-line string parameters and comments in these. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/366> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #511: Create simulations and automatically purge old version
by Einstein Toolkit 17 Aug '11

17 Aug '11

#511: Create simulations and automatically purge old version -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- When I create a new simulation, I go through a cycle of 1. Edit parameter file 2. create-submit 3. Check output 4. Correct errors 5. Purge simulation 6. Go to 1 This cycle can happen several times for a new parameter file, and there is no value to me in keeping the old broken versions of the simulation around, and I don't want to have to keep choosing a new name for the simulation anyway. I propose adding a --purge option to the create[-submit] command which purges the simulation if it already exists. This would avoid me having to run an additional purge command. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/511> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #474: Citations on ET web site don't show up properly
by Einstein Toolkit 17 Aug '11

17 Aug '11

#474: Citations on ET web site don't show up properly -------------------------------------+-------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The citations on the page <http://einsteintoolkit.org/documentation/licenses/> don't show up properly. for example, the web site for Cactus does not show up at all, and the paper for Cactus is listed under a Carpet entry. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/474> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #449: Check for periodicity of initial data with Periodic thorn
by Einstein Toolkit 17 Aug '11

17 Aug '11

#449: Check for periodicity of initial data with Periodic thorn -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: Periodic | -------------------------+-------------------------------------------------- When applying periodic boundary conditions with the Periodic thorn, the thorn could check that the initial data it was given was actually periodic. This might help to track down errors in setting up parameter files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/449> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #509: Cannot cleanup multiple simulations
by Einstein Toolkit 17 Aug '11

17 Aug '11

#509: Cannot cleanup multiple simulations ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The code to clean up multiple simulations given on the cleanup command line was wrong. The attached patch fixes it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/509> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #507: Allow non-simulation directories in simulations directory
by Einstein Toolkit 17 Aug '11

17 Aug '11

#507: Allow non-simulation directories in simulations directory -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory considers all subdirectories of the simulations directory as simulations and emits warnings and spurious messages when running list- simulations. Additional subdirectories might be used to categorise simulations by project or might correspond to simulations run by a previous version of simfactory. The attached patch makes simfactory consider only directories containing a SIMFACTORY/properties.ini file as valid simulations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/507> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #477: Carpet commit f33caf3aba96 (hg) breaks timer output in CCTK_Terminate
by Einstein Toolkit 17 Aug '11

17 Aug '11

#477: Carpet commit f33caf3aba96 (hg) breaks timer output in CCTK_Terminate --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- the commit to make Cactus timers hierarchical breaks eg. the Multipole testsuites with an error: {{{ cactus_devel: /localdata/rhaas3/Cactus_devel/configs/devel/build/Carpet/TimerNode.cc:95: void Carpet::TimerNode::stop(): Assertion `this==d_current' failed. }}} From the comments around the assert (thank you for those, Ian). It seems as if the patch tries to enforce that timer calls are properly nested ie. start_timer_A start_time_B stop_timer_B stop_timer_A When I played with timers myself (to write a thorn that traces how the code proceeds through functions and thus wanted to produce a call and timing graph) I found a small number of basic Cactus timers that are not nested like that (Initialization and/or Evolution I think). If this is still the case it would explain the behaviour. I attach the log file of testsuite (Multipole/test_22.par). Backing out of f33caf3aba96 (by applying in inverse patch, hg backout actually gave me conflicts...) makes the testsuite work again. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/477> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011