Trac February 2012

trac@lists.einsteintoolkit.org

1 participants
150 discussions

[Einstein Toolkit] #176: Test parameter files without running them
by Einstein Toolkit 23 Oct '12

23 Oct '12

#176: Test parameter files without running them -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be useful to be able to check that the parameters of a run are OK before running it. Since there can be long queue times on supercomputers, it would be good to do this on a local machine which might not have as much memory as is required for the full run. Currently, running the job would cause memory exhaustion on the smaller machine. One solution would be an additional command-line argument to Cactus --exit-after-paramcheck which stops the run cleanly after the PARAMCHECK Cactus bin. This is preferable to a new Cactus parameter, as it would not require the parameter file to be modified. One could imagine this also being potentially used by simfactory automatically when submitting a job (though this would only work if you could run MPI executables on the head node). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/176> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #535: Add autoconf macro to test C99 style variable declarations
by Einstein Toolkit 23 Oct '12

23 Oct '12

#535: Add autoconf macro to test C99 style variable declarations -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Many compilers don't support C99 style variable declarations in their default settings. We should test this, add certain flags automatically if we can, or abort with a clear error message otherwise. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/535> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #632: Changegroup hook failed when pushing to Carpet repository
by Einstein Toolkit 22 Oct '12

22 Oct '12

#632: Changegroup hook failed when pushing to Carpet repository --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- When I push to the Carpet repository, I get the following message: {{{ remote: error: changegroup.cia hook failed: http://cia.vc returned an error: queued. }}} The push succeeds. What is the cause of this error? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/632> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #359: Add MDB entry for Pandora at LSU
by Einstein Toolkit 22 Oct '12

22 Oct '12

#359: Add MDB entry for Pandora at LSU ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: task | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/359> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #412: Split Appendices
by Einstein Toolkit 22 Oct '12

22 Oct '12

#412: Split Appendices -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, the appendices of the users' guide are repeated into the reference manual. This is somewhat confusing, and causes problems because the appendices cannot easily reference other sections (e.g. "see page 15" doesn't make sense since one doesn't know in which document this will be read). I suggest to split the appendices and have some of them in the users' guide while moving others into the reference manual, so that each appendix is included in only one document -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/412> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #704: Carpet complains about lack of mpi after ExternalLibraries/OpenMPI is built
by Einstein Toolkit 20 Oct '12

20 Oct '12

#704: Carpet complains about lack of mpi after ExternalLibraries/OpenMPI is built ---------------------+------------------------------------------------------ Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ---------------------+------------------------------------------------------ I was able to compile ExternalLibraries/OpenMPI successfully, but the Cactus compilation stops afterwards with the message: /home/bruno/tmp/einstein_dev_maxwell/Cactus/arrangements/Carpet/CarpetLib/src/make.configuration.defn:5: *** Configuration error: The Carpet thorns require MPI. Please configure with MPI, or remove the Carpet thorns from the ThornList.. Stop. make: *** [einstein] Error 2 I indicated in my configuration file the following options: OPENMPI_DIR = BUILD OPENMPI_INSTALL_DIR = /home/bruno/local/gcc4.6.1/openmpi-1.5.4 I have then tried to indicate in my config file these extra options after the library was built (and the rest of Cactus compilation stopped): OPENMPI_DIR = /home/bruno/local/gcc4.6.1/openmpi-1.5.4 OPENMPI_INC_DIRS = /home/bruno/local/gcc4.6.1/openmpi-1.5.4/include OPENMPI_LIB_DIRS = /home/bruno/local/gcc4.6.1/openmpi-1.5.4/lib The config-info file does reflect these choices afterwards, and apparently the flag indicating the presence of mpi library, HAVE_MPI, was set correctly at ~/Cactus/configs/einstein/bindings/Configuration/Capabilities: grep -i have_mpi * cctki_MPI.h:#define HAVE_MPI 1 make.MPI.defn:HAVE_MPI = 1 however since I didn't use the old mechanism to tell Cactus about MPI, the ~/Cactus/configs/einstein/config-data/make.extra.defn doesn't have anything indicating the presence of mpi library there. It seems to me a compilation order issue. Somehow HAVE_MPI definition is coming after Carpet compilation, triggering this error then. Does anyone have any idea where I should look at in order to fix this problem? Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/704> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active
by Einstein Toolkit 19 Sep '12

19 Sep '12

#720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- This is an offshot of a discussion on the Cactus developers mailing list: http://cactuscode.org/pipermail/developers/2011-November/006258.html On 6 Jan 2012 12:54:13 -0500 eschnett said: > What is currently missing is the mechanism that checks that all thorns > providing required capabilities are activated. If they are not, code > in inactive thorns is called -- this is fine as long as no Cactus > infrastructure is used (parameters, scheduled routines, grid > functions, etc.). > > Yes, we should implement the respective checks; yes, we should > automatically activate thorns required for capabilities (and maybe > some others as well?); yes, we should then output this thorn list to > the screen (done anyway) and into a file. > > By the way, Cactus already determines which thorns need to be > activated automatically as a service to the user in the error message > that complains about missing thorns. The idea seems to be to document all thorns whose code is executed in the parameter file. Ian's original need might be served by an "OPTIONAL" statement in configuration.ccl (http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech12.html#x17…) and some #ifdefs, maybe. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/720> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #762: support git-svn repositories
by Einstein Toolkit 17 Sep '12

17 Sep '12

#762: support git-svn repositories ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: enhancement | Status: new Priority: optional | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I have a number of svn repositories that are each wrapped within a git-svn checkout (to more easily handle local modifications). It would be nice to have GetComponents handle these for me in the same way it already handles svn and git repositories. With git-svn checkouts are {{{git svn clone URL DIR}}}, updates are {{{git svn rebase}}}, diff is {{{git diff remotes/git-svn}}} and local changes have to be stashed the way they are with git. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/762> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #745: the flesh allows two implemantion of the same interface to have different default values for restricted parameters
by Einstein Toolkit 05 Sep '12

05 Sep '12

#745: the flesh allows two implemantion of the same interface to have different default values for restricted parameters --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- since the flesh creates paramters for all compiled in (rather than activated) thorns initially, this affects the default value that a thorn sees. Thorns seem to be initialized (and thus their parameter structures being created) in alphabetical order, which means that the thorn alphabetically '''last''' (How, I have no idea, the parameter handling logic seems a bit of a mess) will determine the default parameter value. Attached is a parameter file to demonstrate this with Carpet and PUGH who both declare parameters periodic and periodic_[xyz] but differ in their defaults. To demonstrate, create an executable with only Carpet compiled in and run the parameter file. Then look at the paramters in the checkpoint it creates eg. {{{ h5dump -r -d /Parameters\ and\ Global\ Attributes/All\ Parameters output/checkpoint.chkpt.it_0.h5 | grep periodic }}} Do the same with an executable that contains both PUGH and Carpet. Notice that parameter values are now PUGH's defaults. This can actually cause a runs to abort when recovering from a checkpoint when one switches from an executable with PUGH compiled in to one that does not. (Beyond the fact that some thorn might actually use it's parameters rather than the Carpet/PUGH pair where happily Carpet ignores these parameters and PUGH who actually used them gets to set the default). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/745> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #669: Rewrite users of deprecated HDF5 C++ API
by Einstein Toolkit 04 Sep '12

04 Sep '12

#669: Rewrite users of deprecated HDF5 C++ API ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: task | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- The C++ API for HDF5 is decprecated. We should examine which code uses it, and rewrite it to use the C API instead. This would allow us to use more system-provided HDF5 installations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/669> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2012