Trac December 2010

trac@lists.einsteintoolkit.org

1 participants
102 discussions

[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

[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] #137: Add option to list only active simulations
by Einstein Toolkit 07 Dec '10

07 Dec '10

#137: Add option to list only active simulations -------------------------+-------------------------------------------------- Reporter: anonymous | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- list-simulations produces too much output; there should be an option to list only active simulations, or only simulations that were active in the past day/week. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/137> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #134: Add EOS_Omni to standard thorn list
by Einstein Toolkit 06 Dec '10

06 Dec '10

#134: Add EOS_Omni to standard thorn list ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Since GRHydro depends on EOS_Omni, we should add it to the standard manifest. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/134> 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

Re: [ET Trac] [Einstein Toolkit] #61: make COMPONENTLIST_TARGET 'stable'
by Einstein Toolkit 04 Dec '10

04 Dec '10

#61: make COMPONENTLIST_TARGET 'stable' ----------------------------+----------------------------------------------- Reporter: knarf | Owner: eric9 Type: enhancement | Status: closed Priority: minor | Milestone: Component: GetComponents | Version: Resolution: fixed | Keywords: ----------------------------+----------------------------------------------- Changes (by eric9): * status: accepted => closed * resolution: => fixed Comment: issue resolved in revision 706 of the svn version -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/61#comment:5> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2010