Trac November 2010

trac@lists.einsteintoolkit.org

1 participants
70 discussions

[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] #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] #128: Mailing list not sending copies of own messages
by Einstein Toolkit 08 Dec '10

08 Dec '10

#128: Mailing list not sending copies of own messages --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- I have sent several messages to the mailing list users(a)einsteintoolkit.org since 17-Nov-2010 and have not received these back. Other people have received them. On and before 17-Nov-2010, I used to receive my own messages as well. Receiving your own messages sent to the list is important as otherwise it is not possible to know if the messages have made it or not. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/128> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #82: Add thornlist default to defs.local.ini.simple
by Einstein Toolkit 06 Dec '10

06 Dec '10

#82: Add thornlist default to defs.local.ini.simple --------------------------------------+------------------------------------- Reporter: barry.wardell@… | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | --------------------------------------+------------------------------------- If a user doesn't specify a thornlist, they only the Cactus flesh is built, but SimFactory doesn't warn that this is the case. I think that if you don't specify a thornlist, it should be an error/warning. Additionally, I think it would be helpful to add something like [default] thornlist = manifest/einsteintoolkit.th to defs.local.ini.simple to make things easier for new users. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/82> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #76: GetComponents should not create links if repository cannot be checked out
by Einstein Toolkit 04 Dec '10

04 Dec '10

#76: GetComponents should not create links if repository cannot be checked out ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents should not create soft links into a (git) repository if the repository could not be checked out. It is confusing to have broken soft links there. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/76> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #75: Checkout/update timestamp
by Einstein Toolkit 04 Dec '10

04 Dec '10

#75: Checkout/update timestamp ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ It would be quite useful to get an idea of when a given Cactus tree was last updated. For example, GetComponents could write some sort of log file with a timestamp, along the lines of "02-Nov-2010: 19:34: Updated from thornlist http://...". If the checkout failed, this could also be recorded there so that you know the checkout is not really up to date. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/75> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #65: Simulation domain volume and reduction weight sum differ
by Einstein Toolkit 03 Dec '10

03 Dec '10

#65: Simulation domain volume and reduction weight sum differ ---------------------+------------------------------------------------------ Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: blocker | Milestone: Component: Carpet | Version: Keywords: | ---------------------+------------------------------------------------------ When running the newest Mercurial version of Carpet with the Llama multipatch infrastructure, I get the error INFO (CarpetReduce): Simulation domain volume: 1 INFO (CarpetReduce): Reduction weight sum: 3718016 ESC[1mWARNING level 0 in thorn CarpetReduce processor 0 host node024.damiana.admin (line 84 of /home/ianhin/Cactus/llama/arrangements/CarpetHG/CarpetReduce/src/mask_test.c): ->Simulation domain volume and reduction weight sum differ I have reduced the parameter file to the essentials, and it is attached, along with standard output and standard error. The whole simulation is on damiana in /lustre/AEI/ianhin/simulations/chgbug_8. Versions of components: Carpet: 3190:c24983d83cdd Llama: 85983412998b4fa7bf2ea7da93db427c471b7c72 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/65> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #88: Error messages during cleanup are not printed
by Einstein Toolkit 29 Nov '10

29 Nov '10

#88: Error messages during cleanup are not printed ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- When a simulation is submitted, all existing restarts are automatically cleaned up. This happens with verbose=false, so that no messages are printed to the screen. When there is an error during cleanup, simfactory aborts without showing any screen output. All error messages should always be printed, independent of the verbosity level. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/88> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #85: --reconfig seems to lead to --clean
by Einstein Toolkit 29 Nov '10

29 Nov '10

#85: --reconfig seems to lead to --clean ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- When I use --reconfig for building, SimFactory also assumes that --clean is used, although I did not. I build with the command ./simfactory/sim build --debug --reconfig and after reconfiguring, SimFactory outputs build_clean: True removeConfig: False Cleaning sim-debug and then cleans the configuration. This should not be the case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/85> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2010