Trac February 2012

trac@lists.einsteintoolkit.org

1 participants
150 discussions

[Einstein Toolkit] #531: Problem with adding/removing configuration.ccl files
by Einstein Toolkit 11 Aug '12

11 Aug '12

#531: Problem with adding/removing configuration.ccl files ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Cactus doesn't handle well adding or removing configuration.ccl files. When a new configuration.ccl file is added, Cactus ignores it until the next "rebuild" (i.e. until another ccl file changes, until the thorn list changes, or until the user calls *-rebuild explicitly). When a configuration.ccl file is removed, make aborts with an error message, and a rebuild is forced. One way to remedy this would be to have (empty) configuration.ccl file in all thorns. After all, param.ccl and schedule.ccl files also need to be present even if they are empty. This would also remove a bit of complex logic from the Cactus make system. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/531> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #628: Configuring on Kraken leads to warnings
by Einstein Toolkit 11 Aug '12

11 Aug '12

#628: Configuring on Kraken leads to warnings -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Using current simfactory to build on Kraken leads to the following warning during configuration: {{{ This is probably a Cray XT4 series system. Using known-architectures xt4-cray-linux This is an Cray XT4: you always need MPI! Forcing MPI to NATIVE. Unknown Linux f90 compiler. Please add appropriate information to /nics/d/home/hinder/Cactus/EinsteinToolkit/lib/make/known- architectures/linux and send the updated file to CactusMaint We will try anyway ... }}} Cactus should learn about this system. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/628> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #420: newest revision of simfactory 2.0 submit three instead of one job
by Einstein Toolkit 11 Aug '12

11 Aug '12

#420: newest revision of simfactory 2.0 submit three instead of one job ----------------------------------------------+----------------------------- Reporter: alexander.beck-ratzka@… | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: ET_2010_11 Keywords: | ----------------------------------------------+----------------------------- I am submitting a simulation using simfactory with the command: [snip] simfactory/bin/sim submit test-whisky-openmp --configuration test-whisky- openmp --parfile=whisky-openmp-test-ali.par --verbose --walltime=48:00:00 --procs=16 --ppn=4 --num-threads=4 --machine=damiana --queue=intel.q [snip] sim then comes with the messages: [snip] Info: Simfactory command: simfactory/bin/../lib/sim.py "submit" "test- whisky-openmp" "--configuration" "test-whisky-openmp" "--parfile=whisky- openmp-test-ali.par" "--verbose" "--walltime=48:00:00" "--procs=16" "-- ppn=4" "--num-threads=4" "--machine=damiana" "--queue=intel.q" Info: Version 1331M The Simulation Factory: Manage Cactus simulations Info: defs: /home/alibeck/programme/Cactus- Luca/Cactus/simfactory/etc/defs.ini Info: defs.local: /home/alibeck/programme/Cactus- Luca/Cactus/simfactory/etc/defs.local.ini Info: Cactus Directory: /home/alibeck/programme/Cactus-Luca/Cactus Info: simenv.COMMAND: submit Info: Executing command: submit Info: Assigned restart_id of: 0002 Info: Found the following restart_ids: [0, 1] Info: Maximum restart id determined to be: 0001 Assigned restart id: 2 Info: Simulation is inactive: submitting Info: Job allocation information: Info: System: nodes=170 cores/node=4 threads/process=4 Info: Requested: nodes=4 cores=16 cores/node=4 Info: Run: processes=4 threads=16 threads/process=4 Info: Distribution: processes/node=1 threads/node=4 Info: Ratio: threads/core=1.000 cores/thread=1.000 Info: writing to internalDir: /lustre/AEI/alibeck/simulations/test-whisky- openmp/output-0002/SIMFACTORY Info: saving substituted submitscript contents to: /lustre/AEI/alibeck/simulations/test-whisky- openmp/output-0002/SIMFACTORY/SubmitScript Executing submit command: qsub /lustre/AEI/alibeck/simulations/test- whisky-openmp/output-0002/SIMFACTORY/SubmitScript Submit finished, job id is 259460 Info: Restart 2 is active Info: Assigned restart_id of: 0003 Info: Found the following restart_ids: [0, 1, 2, 2] Info: Maximum restart id determined to be: 0002 Assigned restart id: 3 Info: Simulation is active: presubmitting Info: Job allocation information: Info: System: nodes=170 cores/node=4 threads/process=4 Info: Requested: nodes=4 cores=16 cores/node=4 Info: Run: processes=4 threads=16 threads/process=4 Info: Distribution: processes/node=1 threads/node=4 Info: Ratio: threads/core=1.000 cores/thread=1.000 Info: writing to internalDir: /lustre/AEI/alibeck/simulations/test-whisky- openmp/output-0003/SIMFACTORY Info: saving substituted submitscript contents to: /lustre/AEI/alibeck/simulations/test-whisky- openmp/output-0003/SIMFACTORY/SubmitScript Executing submit command: qsub /lustre/AEI/alibeck/simulations/test- whisky-openmp/output-0003/SIMFACTORY/SubmitScript Submit finished, job id is 259461 Info: Restart 2 is active Info: Assigned restart_id of: 0004 Info: Found the following restart_ids: [0, 1, 2, 2, 3] Info: Maximum restart id determined to be: 0003 Assigned restart id: 4 Info: Simulation is active: presubmitting Info: Job allocation information: Info: System: nodes=170 cores/node=4 threads/process=4 Info: Requested: nodes=4 cores=16 cores/node=4 Info: Run: processes=4 threads=16 threads/process=4 Info: Distribution: processes/node=1 threads/node=4 Info: Ratio: threads/core=1.000 cores/thread=1.000 Info: writing to internalDir: /lustre/AEI/alibeck/simulations/test-whisky- openmp/output-0004/SIMFACTORY Info: saving substituted submitscript contents to: /lustre/AEI/alibeck/simulations/test-whisky- openmp/output-0004/SIMFACTORY/SubmitScript Executing submit command: qsub /lustre/AEI/alibeck/simulations/test- whisky-openmp/output-0004/SIMFACTORY/SubmitScript Submit finished, job id is 259462 [snip] As a result three jobs are queued. [snip] qstat job-ID prior name user state submit/start at queue slots ja-task-ID ----------------------------------------------------------------------------------------------------------------- 259460 0.00000 test-whisk alibeck qw 04/29/2011 10:26:55 16 259461 0.00000 test-whisk alibeck hqw 04/29/2011 10:26:56 16 259462 0.00000 test-whisk alibeck hqw 04/29/2011 10:26:56 16 [snip] What is going wrong here? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/420> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #380: AHFinderDirect failure with qc0-mclachlan.par
by Einstein Toolkit 10 Aug '12

10 Aug '12

#380: AHFinderDirect failure with qc0-mclachlan.par --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2011_05 Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- Trying to run the par/qc0-mclachlan.par in the ET trunk gives the following error: INFO (AHFinderDirect): proc 0: searching for horizons 1,5/6 WARNING level 0 in thorn CarpetInterp processor 0 host kop193.datura.admin (line 1683 of /home/ianhin/Cactus/etrelease/arrangements/Carpet/CarpetInterp/src/interp.cc): -> Grid function "AHFINDERDIRECT::ahmask" has only 1 active time levels on refinement level 1; this is not en ough for time interpolation See also #373, which might be related. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/380> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #676: GRHydro/MHD ist not fully multipatch aware yet
by Einstein Toolkit 10 Aug '12

10 Aug '12

#676: GRHydro/MHD ist not fully multipatch aware yet -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- eg. ReconstructPoly uses Bvec and vel directly. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/676> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #488: Reduce space taken by Formaline tarballs
by Einstein Toolkit 10 Aug '12

10 Aug '12

#488: Reduce space taken by Formaline tarballs -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: Formaline | -------------------------+-------------------------------------------------- When syncing lightweight data of simulations from a cluster, much of the time and disk space on the local system is taken with Formaline tarballs. It would be good to reduce this. I propose opportunistically replacing the generated tarballs with hard- links to existing tarballs on the same filesystem after Formaline has written them to the new output directory if the files compare equal. These could be from previous restarts of the same simulation when using simfactory. Then, if an entire simulation is rsynced with the appropriate options, hard-links will be transferred as hard-links, and the overall transfer time and disk space used will be significantly reduced. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/488> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #708: Cannot submit on Surveyor
by Einstein Toolkit 10 Aug '12

10 Aug '12

#708: Cannot submit on Surveyor ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Surveyor is a BlueGene/P, and the operating system apparently does not support hard links. Submitting a job via Simfactory fails: DISTRIBUTE: Executing: ./simfactory/bin/sim --remote surveyor create- submit testsuite-surveyor-2011.12.21-19.31.05 --testsuite --parfile=recover.par --walltime=2:00:00 --procs=4 --ppn-used=4 --num- threads=2 Skeleton Created Job directory: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05" Executable: "/gpfs/home/eschnett/Cbeta/exe/cactus_sim" Option list: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05/SIMFACTORY/cfg/OptionList" Submit script: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05/SIMFACTORY/run/SubmitScript" Run script: "/pvfs-surveyor/eschnett/simulations/testsuite- surveyor-2011.12.21-19.31.05/SIMFACTORY/run/RunScript" Assigned restart id: 0 Copying testsuite data Traceback (most recent call last): File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 147, in ? main() File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 143, in main CommandDispatch() File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 105, in CommandDispatch module.main() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 397, in main CommandDispatch() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 376, in CommandDispatch exec("command_%s()" % command) File "<string>", line 1, in ? File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 161, in command_create_submit command_submit() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 262, in command_submit restart.userSubmit(simulationName) File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 346, in userSubmit self.submit(submitScript) File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 739, in submit self.copyTestsuiteData() File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 487, in copyTestsuiteData os.link(self.Properties.executable, os.path.join(testexe,simlib.BaseName(self.Properties.executable))) OSError: [Errno 95] Operation not supported Simfactory should catch this, and should copy the file if it cannot be linked. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/708> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #730: The mojave variable "thornlist" cannot deal with absolute path names; update repo fails then...
by Einstein Toolkit 08 Aug '12

08 Aug '12

#730: The mojave variable "thornlist" cannot deal with absolute path names; update repo fails then... ---------------------+------------------------------------------------------ Reporter: alibeck | Owner: sbrandt Type: defect | Status: new Priority: blocker | Milestone: Component: Mojave | Version: Keywords: | ---------------------+------------------------------------------------------ Using Eclispe (indigo classic), I have tried to build with a new thornlist. Therefore I have entered the following name in mojave -> edit variables /home/alibeck/Cactus-Simfact2-NewRepos-save/Cactus/test-ali.th Staring then "update repo" gives me: [1m[31mError: [0mCould not open Cactus//home/alibeck/Cactus-Simfact2 -NewRepos-save/Cactus/test-ali.th So mojave tries to open a file called Cactus//home/alibeck/Cactus-Simfact2-NewRepos-save/Cactus/test-ali.th instead of /home/alibeck/Cactus-Simfact2-NewRepos-save/Cactus/test-ali.th -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/730> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #177: EXC_BAD_ACCESS in CarpetIOASCII
by Einstein Toolkit 06 Aug '12

06 Aug '12

#177: EXC_BAD_ACCESS in CarpetIOASCII --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- I am trying to run a minimal parameter file for testing purposes (attached). Cactus gets as far as printing the iteration 0 info line and then appears to hang. When I run in a debugger, it reports: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 1378 switch (vartype) { (gdb) bt #0 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 #1 0x0000000100b5b7ee in CarpetIOASCII::IOASCII<0>::OutputDirection (cctkGH=0x109f073f0, vindex=0, alias={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06c1c8 "carpet::timing"}}, basefilename={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06ba68 "minimal/carpet::timing"}}, dirs=@0x7fff5fbfd150, is_new_file=true, truncate_file=true) at ioascii.cc:610 #2 0x0000000100b554c4 in CarpetIOASCII::IOASCII<0>::OutputVarAs (cctkGH=0x109f073f0, varname=0x10a06c170 "CARPET::physical_time_per_hour", alias=0x10a06be00 "carpet::timing") at ioascii.cc:480 #3 0x0000000100b57370 in CarpetIOASCII::IOASCII<0>::TriggerOutput (cctkGH=0x109f073f0, vindex=0) at ioascii.cc:359 #4 0x0000000100b542b7 in CarpetIOASCII::IOASCII<0>::OutputGH (cctkGH=0x109f073f0) at ioascii.cc:239 #5 0x000000010329a006 in Carpet::OutputGH (cctkGH=0x109f073f0) at OutputGH.cc:55 #6 0x0000000103293b25 in Carpet::OutputGH (where=0x104c70f3c "Initialise::CallAnalysis", cctkGH=0x109f073f0) at Initialise.cc:1382 #7 0x000000010328d432 in Carpet::CallAnalysis (cctkGH=0x109f073f0) at Initialise.cc:530 #8 0x00000001032892d4 in Carpet::Initialise (fc=0x7fff5fbfe2b0) at Initialise.cc:118 #9 0x000000010005806a in main (argc=4, argv=0x7fff5fbfe318) at flesh.cc:80 I do not see how this line "switch(vartype)" where vartype is declared on the stack, could lead to this error. This configuration has been rebuilt with -O0 (Intel compiler) and debugging enabled. This is with the current production (Git) version of Carpet running on Mac OS 10.6.5. The code is compiled as 64 bit. This parameter file has worked in the past, though with 32 bit on Mac OS 10.5. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/177> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #465: Hydro_InitExcision test cases take a long time
by Einstein Toolkit 04 Aug '12

04 Aug '12

#465: Hydro_InitExcision test cases take a long time -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I am just running all test cases with an executable without optimisation, and I find that Hydro_InitExcision takes a long time. While most other test cases finish in a few minutes, Hydro_InitExcision takes two hours to run. The test cases should be reduced in number, size, or duration. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/465> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

← Newer
1
...
5
6
7
8
9
10
11
...
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