Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #161: Support valgrind as debug/performance tool
by Einstein Toolkit 22 Dec '10

22 Dec '10

#161: Support valgrind as debug/performance tool -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Support valgrind, in particular the --cachegrind tool, with SimFactory as a performance measurement tool. The cache characteristics should be taken out of the MDB. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/161> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #158: Logging in SimFactory
by Einstein Toolkit 22 Dec '10

22 Dec '10

#158: Logging in SimFactory ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: task | Status: new Priority: critical | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The logging facility in SimFactory is supposed to keep track of all actions performed on a simulation. That is, there needs to be exactly one log file per simulation. It is not necessary to have a log file within the Cactus source tree, since this file could go away at any time, and is not connected to any simulation. The log file should be created when a simulation is created. Only important actions -- actions that potentially modify the state of the simulation -- should be logged. For example, if a new restart is created, or if a restart is stopped, or if a simulation is archived, then this should be logged. If a simulation is only examined, then this should not be logged. Python has a convenient logging facility. This should be used if possible. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/158> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #79: Running on Damiana fails
by Einstein Toolkit 21 Dec '10

21 Dec '10

#79: Running on Damiana fails --------------------------------------+------------------------------------- Reporter: barry.wardell@… | Owner: mthomas Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: Keywords: | --------------------------------------+------------------------------------- The compute nodes on Damiana are named nodeXXX, which does not match the aliaspattern for Damiana in the mdb. The quick fix is to change the aliaspattern to: aliaspattern = ^(((login-)?damiana)|(sl-\d\d)|node\d\d\d)(\.aei\.mpg\.de|\.damiana\.admin)?$ although this might interfere with other machines which also have their compute nodes named nodeXXX. A better fix would probably be to add a --machine=... option when running so that SimFactory does not need to guess which machine it's on from the aliaspattern. I believe a similar problem also affects Kraken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/79> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #151: simfactory.org is down
by Einstein Toolkit 21 Dec '10

21 Dec '10

#151: simfactory.org is down ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: critical | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The web site simfactory.org shows only the default Apache screen. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/151> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #130: Add --machine=... option to all submit scripts
by Einstein Toolkit 21 Dec '10

21 Dec '10

#130: Add --machine=... option to all submit scripts ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- We need to add a --machine=... option to all submit script, so that the aliaspatterns don't need to match the compute nodes' names any more. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/130> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #86: Sync fails, the outputs "sync done"
by Einstein Toolkit 21 Dec '10

21 Dec '10

#86: Sync fails, the outputs "sync done" ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- In a situation where syncing to a remote machine fails, SimFactory prints the error message from rsync, and then continus to output "Sync complete." It should not do this -- it should either abort after the rsync error, or should output an error message. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/86> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #81: Rename --remotemachine= to --remote
by Einstein Toolkit 21 Dec '10

21 Dec '10

#81: Rename --remotemachine= to --remote --------------------------------------+------------------------------------- Reporter: barry.wardell@… | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | --------------------------------------+------------------------------------- With the perl version of simfactory, it was possible to run remote commands using eg. 'sim remote damiana submit...'. The new version doesn't seem to have this and it is necessary to use --remotemachine=... instead, which is a bit more annoying to type. It would be nice to add 'sim remote' to the new simfactory, or as Erik suggests: I suggest to rename "--remotemachine" to "--remote"; this would allow the syntax sim --remote damiana submit ... -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/81> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #152: New options CPP_DEBUG_FLAGS etc.
by Einstein Toolkit 21 Dec '10

21 Dec '10

#152: New options CPP_DEBUG_FLAGS etc. -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to add new configuration flags CPP_DEBUG_FLAGS etc., which allow passing special CPP flags for debugging. These complement the existing C_DEBUG_FLAGS and the (global) CPPFLAGS. In particular, I suggest to add the following flags: CPP_DEBUG_FLAGS FPP_DEBUG_FLAGS CPP_OPTIMISE_FLAGS FPP_OPTIMISE_FLAGS CPP_PROFILE_FLAGS FPP_PROFILE_FLAGS CPP_OPENMP_FLAGS FPP_OPENMP_FLAGS CPP_WARN_FLAGS FPP_WARN_FLAGS Applications are e.g. adding -Wall to CPP_WARN_FLAGS, or -fopenmp to CPP_OPENMP_FLAGS. I enclose a patch that implements this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/152> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #69: Formaline might stop build because of errors reported by tar
by Einstein Toolkit 19 Dec '10

19 Dec '10

#69: Formaline might stop build because of errors reported by tar --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2010_11 Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- Beginning with version 1.16 of gnu tar: <quote> After creating an archive, tar exits with code 1 if some files were changed while being read. Previous versions exited with code 2 (fatal error), and only if some files were truncated while being archived. </quote> Even reading a file (as is done when compiling it in parallel) will change it in tar's view, because this changes the atime of the file. There does not seem to be an option which turns this new behavior off. Instead it is recommended to check the exit code of tar which is 0: if everything went ok 1: if files changed while being read/written 2: if some other error occurs. This means that Formaline should treat an exit code of 1 in tar as 'ok', while currently it aborts the build. However, this is safely true only for gnu tar. For example the version of tar on the 'pelican' system states: <quote> 0 Successful completion. >0 An error occurred. </quote> This is too vague to decide if ignoring an exit code of 1 can also here be ignored. File changes are a kind of error - of a kind one might be able to ignore. The documentation of this old version of tar doesn't mention which values are actually used for which errors though. Somewhere else I found [http://aplawrence.com/Bofcusm/2073.html this]: <quote> 0 - success 1 - bad directory tree, failed to extract a requested file, input file same as output file, failed to open input file, could not create link, link table malloc failure 2 - internationalization error that should never occur, checksum error 5 - checksum error 9 (EBADF) - error reading /etc/default/tar, misplaced end of volume </quote> So, it is probably not safe to assume that an exit value of 1 always means 'success' for any version of tar, in the case of Formaline. How should we proceed with Formaline? The current state is not desirable. As far as I can see we have two options: 1) Assume that an exit value of 1 to be a 'success'. I do have a patch for this. 2) Test for gnu tar and only then assume 1) Opinions? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/69> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #144: GetComponents hangs during download on https:// servers
by Einstein Toolkit 16 Dec '10

16 Dec '10

#144: GetComponents hangs during download on https:// servers ---------------------------------------+------------------------------------ Reporter: anonymous | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: svn certificate authority | ---------------------------------------+------------------------------------ When I run GetComponents, it hangs on all components found at https://svn.xxx domains, particularly https://svn.cct.lsu.edu. Running interactively using SVN, it seems likely to be a failure to respond to the prompt about accepting the certificate authority. I'm running the MacPorts version of svn 1.6.4 on a PowerMac, OSX10.5.8. The response to a hand-typed svn command is below. svn checkout https://svn.cct.lsu.edu/repos/numrel/simfactory/trunk simfactory Error validating server certificate for 'https://svn.cct.lsu.edu:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.cct.lsu.edu - Valid: from Sat, 03 Apr 2010 18:06:12 GMT until Sun, 03 Apr 2011 18:06:12 GMT - Issuer: lsu, edu - Fingerprint: 13:58:a8:e6:fb:3b:54:17:0a:9d:ab:9f:f9:2c:80:06:01:41:2e:52 (R)eject, accept (t)emporarily or accept (p)ermanently? p -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/144> 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