Trac May 2011

trac@lists.einsteintoolkit.org

1 participants
122 discussions

[Einstein Toolkit] #433: GetComponents to report updated components
by Einstein Toolkit 11 May '11

11 May '11

#433: GetComponents to report updated components ---------------------------------------+------------------------------------ Reporter: baiotti@… | Owner: eric9 Type: enhancement | Status: new Priority: optional | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------------------+------------------------------------ I think it would be useful if "GetCompontents --update" reported which components and which files have been actually updated (they are usually a few, if one updates periodically). This can be achieved with the --verbose option, but then the output is larger than needed, I think. The current version (with the --version option) outputs, for example: Updating module: LSUThorns/SummationByParts from repository: https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/trunk located in: ./arrangements Executing: svn update --non-interactive In: ./arrangements/LSUThorns/SummationByParts U src/call_derivs2.c Updated to revision 127. I think that even without the --verbose option the lines Updating module: LSUThorns/SummationByParts U src/call_derivs2.c Updated to revision 127. should be output, while the lines from repository: https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/trunk located in: ./arrangements Executing: svn update --non-interactive In: ./arrangements/LSUThorns/SummationByParts report information that is not usually needed (not to speak of the initial long ,info. stuff) and therefore should be output only if the --verbose option is invoked. In brief, I would like the output of GetComponents --update to be like Updating module: LSUThorns/SummationByParts U src/call_derivs2.c Updated to revision 127. Cheers, Luca -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/433> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #432: SummationByParts: typo in arguments of deriv2_mixed call.
by Einstein Toolkit 11 May '11

11 May '11

#432: SummationByParts: typo in arguments of deriv2_mixed call. ------------------------------------------+--------------------------------- Reporter: eloisa.bentivegna@… | Type: defect Status: new | Priority: major Milestone: | Component: EinsteinToolkit thorn Version: | Keywords: ------------------------------------------+--------------------------------- On line 85 of call_derivs2.c, the call CCTK_FNAME(deriv2_mixed)(&cctkGH_,&dir1,&dir2,var,&ni,&nk,&nk,dvar2,&table_handle); should be CCTK_FNAME(deriv2_mixed)(&cctkGH_,&dir1,&dir2,var,&ni,&nj,&nk,dvar2,&table_handle); -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/432> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #375: RotatingSymmetry*: Improve performance
by Einstein Toolkit 08 May '11

08 May '11

#375: RotatingSymmetry*: Improve performance -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patches depend on the new Slab API provided by ticket #374: Use the new Slab API to set up the communication schedule only once (per regridding), which saves some communication time when applying symmetries. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/375> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #374: CactusNumeric/Slab: Improve performance
by Einstein Toolkit 08 May '11

08 May '11

#374: CactusNumeric/Slab: Improve performance -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patch does the following, prompted by performance problems reported by Christian Ott: Reorganise some of the internals of thorn Slab: Use LoopControl to parallelise loops via OpenMP. Refactor the "work horse" routines that perform the actual copy routines. These routines are specialised for common cases that need to execute efficiently, in particular for the cases encountered in RotatingSymmetry90 and RotatingSymmetry180 when handling CCTK_REAL variables. Offer an additional API (Slab_MultiTransfer_Init, Slab_MultiTransfer_Apply, Slab_MultiTransfer_Finalize) that calculates the communication schedule only once, and then re-uses it in further calls. This avoids some communication overhead. Remove old CVS header comments. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/374> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #427: Cannot update manifest to Mercurial version of Carpet
by Einstein Toolkit 05 May '11

05 May '11

#427: Cannot update manifest to Mercurial version of Carpet ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: critical | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I updated my manifest to using the Mercurial version of Carpet. Since I was using this version before, there was no change except that there is now also an anonymous url available. When I try to update, I receive the error message that the repo url changed, although it did not change at all. My repo configuration was before: # Carpet, the AMR driver !TARGET = $ARR !TYPE = git !AUTH_URL = carpetgit@carpetcode.org:carpet !URL = git://carpetcode.org/carpet # For experimental version, comment previous three lines and uncomment next two # Note that you will need to get access first (ask Erik Schnetter) !TYPE = hg !URL = ssh://carpetmercurial@carpetcode.org/carpet It is now: # Carpet, the AMR driver !TARGET = $ARR !TYPE = hg !AUTH_URL = ssh://carpetmercurial@carpetcode.org/carpet !URL = http://www.carpetcode.org/hg/carpet # For the git version of Carpet, comment the previous three lines and # uncomment the next three #!TYPE = git #!AUTH_URL = carpetgit@carpetcode.org:carpet #!URL = git://carpetcode.org/carpet In particular, the url did not change, but it moved from URL to AUTH_URL, while the URL method is now new. The url required authorization all along, but since GetComponents does not support having an AUTH_URL without having a URL, it was given as URL. When I give the command $ ./bin/GetComponents --update --root=. manifest/einsteintoolkit.th I receive the error message: Error: The URL for Carpet/doc has changed, please perform a clean checkout. Note that I don't use (and I think I never did use) the -a flag for GetComponents. I checked the repository, and the current url is the same as in the manifest: $ (cd repos/carpet; hg showconfig paths.default) ssh://carpetmercurial@carpetcode.org/carpet Where does GetComponents store the previous url? How can I make it believe that my repo url did not actually change? Is this connected with switching from an anonymous to an authorized checkout? If so, how do I make this switch "officially"? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/427> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #422: Cactus make problems
by Einstein Toolkit 04 May '11

04 May '11

#422: Cactus make problems ----------------------------------------------+----------------------------- Reporter: alexander.beck-ratzka@… | Type: defect Status: new | Priority: major Milestone: | Component: Cactus Version: | Keywords: ----------------------------------------------+----------------------------- I have a make problem with ther new cactus revision. Make fails with the error: [snip] Checking status of thorn CarpetControl ________________________________________________________________________ Preprocessing /home/alibeck/programme/Cactus- Luca/Cactus/arrangements/Whisky_Exp/CarpetControl/src/CarpetControl.cc Compiling /home/alibeck/programme/Cactus- Luca/Cactus/arrangements/Whisky_Exp/CarpetControl/src/CarpetControl.cc /home/alibeck/programme/Cactus- Luca/Cactus/arrangements/Whisky_Exp/CarpetControl/src/CarpetControl.cc(20): error: cannot overload functions distinguished by return type alone void CarpetControl_Initialize(void) ^ compilation aborted for /home/alibeck/programme/Cactus-Luca/Cactus/configs /carpet-luca-cactus-new-cactus/build/CarpetControl/CarpetControl.cc (code 2) make[3]: *** [CarpetControl.cc.o] Error 2 make[2]: *** [make.checked] Error 2 make[1]: *** [/home/alibeck/programme/Cactus-Luca/Cactus/configs/carpet- luca-cactus-new-cactus/lib/libthorn_CarpetControl.a] Error 2 make: *** [carpet-luca-cactus-new-cactus] Error 2 [snip] The make dost not fail using the revision r4620 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/422> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #383: SimFactory 1 does not create source directory on login
by Einstein Toolkit 02 May '11

02 May '11

#383: SimFactory 1 does not create source directory on login ------------------------+--------------------------------------------------- Reporter: hinder | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: ET_2011_05 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- If I run "sim login <machine>" to a machine where the remote source directory does not exist, the login fails with bash: line 0: cd: /nics/d/home/hinder/Cactus/etrelease: No such file or directory Connection to kraken-gsi2.nics.teragrid.org closed. If I run a "sim sync" first, then a subsequent sim login works correctly. I propose that simfactory should create the required directories before logging in. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/383> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #242: build fails after running out of disk space
by Einstein Toolkit 02 May '11

02 May '11

#242: build fails after running out of disk space ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- After running out of disk space (and then removing 16 GByte), building fails on numrel09: $ ./bin/sim build DEBUG: Simfactory command: ./bin/../simfactory/lib/sim.py "build" DEBUG: Version exported The Simulation Factory: Manage Cactus simulations Info: defs: /home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/etc/defs.ini Info: defs.local: /home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/etc/defs.local.ini Info: Executing command: build Using configuration: sim Info: Cactus Directory: /home/eschnett/EinsteinToolkit-hg-vanilla Traceback (most recent call last): File "./bin/../simfactory/lib/sim.py", line 142, in <module> main() File "./bin/../simfactory/lib/sim.py", line 139, in main CommandDispatch() File "./bin/../simfactory/lib/sim.py", line 106, in CommandDispatch module.main() File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 420, in main CommandDispatch() File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 347, in CommandDispatch exec("command_%s()" % command) File "<string>", line 1, in <module> File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 391, in command_build PrepConfiguration(config) File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 58, in PrepConfiguration prop.init(propertiesFile) File "/home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/lib/restartlib.py", line 101, in init self.ImportProperties() File "/home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/lib/restartlib.py", line 107, in ImportProperties for key in section.keys(): AttributeError: 'NoneType' object has no attribute 'keys' This looks as if some internal information about the build has become corrupt, maybe because of a partially written file. This may be a rare case not worth handling elegantly. However -- what should I do now? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/242> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #426: Fortran module files should not go into scratch directory
by Einstein Toolkit 02 May '11

02 May '11

#426: Fortran module files should not go into scratch directory ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- The Cactus build system currently cds into the configuration's scratch directory before compiling any file, and accumulates all Fortran module (.mod) files there. This results in a very large directory, and does not separate thorns from each other. This also makes it difficult to delete all built files from a single thorn, which is often convenient for debugging. Instead, Fortran module files should be written into the thorn's object directory. Cactus should then set the Fortran include path correctly so that other thorns' module files are found, if this thorn declared the dependency onto the other thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/426> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #424: Release presubmitted, held jobs if necessary
by Einstein Toolkit 01 May '11

01 May '11

#424: Release presubmitted, held jobs if necessary ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- If a presubmitted job B depends on job A, and if job A finishes before job B is submitted, then job B will be held and will never be released. SimFactory should check for this condition after submitting job B, and should explicitly released job B if job A does not exist any more. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/424> 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 May 2011