Trac July 2012

trac@lists.einsteintoolkit.org

1 participants
161 discussions

[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] #767: removing the last REQUIRES item from configuration.ccl leads to build failures
by Einstein Toolkit 10 Aug '12

10 Aug '12

#767: removing the last REQUIRES item from configuration.ccl leads to build failures --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- The underlying issue seems to be that changing configuration.ccl does not necessarily rebuild all files the were generated using information in it. to reproduce: # get a fresh ET checkout (trunk will do) # add to {{{arrangements/EinsteinBase/CoordGauge/configuration.ccl}}} {{{ REQUIRES Carpet }}} # build Cactus # make sure that you have a file {{{configs/et/bindings/Configuration/Thorns/cctki_CoordGauge.h}}}. If such a file does not exists then most likely you did not start from a fresh checkout. touch the other .ccl files and src/Slicing.c in CoordGauge and build again. The file should appear. Make sure that {{{configs/et/build/CoordGauge/Slicing.c.d}}} contains {{{.../configs/et/bindings/include/../Configuration/Thorns/cctki_CoordGauge.h}}} if not, same as above. # remove the {{{REQUIRES}}} line you added # try to build Cactus # the build should fail with: {{{ Checking status of thorn CoordGauge make[2]: *** [make.checked] Error 2 make[1]: *** [/data/rhaas/postdoc/gr/ET/configs/et/lib/libthorn_CoordGauge.a] Error 2 make: *** [et] Error 2 }}} If you make is the buggy version 3.81 then no reason is given. (make SILENT=no or make -d does not help you either) If you are lucky and have a non buggy version of make (https://savannah.gnu.org/bugs/?15110#comment7) then it might actually tell you that it cannot find {{{ configs/et/bindings/Configuration/Thorns/cctki_CoordGauge.h}}}. To test this touch the file and try to build again. It should work now. Also Slicing.c.d will no longer contain a reference to the offending file. A workaround is to not unlink {{{cctki_CoordGauge.h}}} in {{{lib/sbin/CreateConfigurationBindings.pl}}} around line 176. This generates an empty file which makes make happy. To work around the buggy make (to get an error message) one can replace all {{{ -include foo bar baz }}} lines by {{{ -include $(filter-out $(wildcard foo bar baz),foo bar baz)) include $(filter $(wildcard foo bar baz),foo bar baz)) }}} ie use {{{-include}}} for non-existing files and {{{include}}} for existing ones. The buggy make is what makes this hard, you don't know why the compilation fails and trying to force recompile of CoordGauge by touching any of its .ccl or source files does not help. I usually ended up doing a realclean. Very annoying if this happens on say Kraken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/767> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #804: Cactus build fails on Kraken
by Einstein Toolkit 10 Aug '12

10 Aug '12

#804: Cactus build fails on Kraken -------------------------------+-------------------------------------------- Reporter: ajith@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: Kraken | -------------------------------+-------------------------------------------- Hello, I'm trying to build the development version of einsteintoolkit on Kraken. The build fails with the following error: $ sim build {{{ checking whether the C compiler (/opt/pgi/9.0.4/linux86-64/9.0/bin/pgcc -g -DCRAY_XT -c99 -Wl,--allow-multiple-definition -Bstatic) works... no configure: error: installation or configuration problem: C compiler cannot create executables (see configs/<configname>/config-data/config.log for details). Error reconfiguring sim-config make: *** [sim-config] Error 2 }}} I see that SimFactory is trying to use /opt/pgi/9.0.4/linux86-64/9.0/bin/pgcc which is no longer there in the system. The available pgi compilers are pgi/11.9.0(default) and pgi/12.1.0. Thanks, Ajith -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/804> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #875: Cactus should define 'restrict', with a value dependent on autoconf information
by Einstein Toolkit 10 Aug '12

10 Aug '12

#875: Cactus should define 'restrict', with a value dependent on autoconf information -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- The Kranc ticket https://github.com/ianhinder/Kranc/issues/62 mentions arguments why to do this: to make certain optimizations possible. While 'restrict' is not a C keyword, many compilers support it, leading to measurable speedup in cases. At the moment Cactus only defines CCTK_RESTRICT, but it has been commented that using this leads to ugly code. Defining 'restrict' would beautify this, as well as make it easier to directly use code which relies on 'restrict' being present (when this isn't actually the case, or is called differently). A counter argument would be that this would effectively introduce a keyword 'restrict' to Cactus. Code using this name already for something else would need to be changed. Given the positive effects of this change I would say that this outweights this potential problem. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/875> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #994: read EOS table on single process the broadcast
by Einstein Toolkit 09 Aug '12

09 Aug '12

#994: read EOS table on single process the broadcast -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: EOS_Omni | -----------------------------------+---------------------------------------- this patch limits IO at startup by having a single process (specifiable via a parameter) read the table and the MPI broadcast the data to the others. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/994> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #903: Build of Mojave Project fails
by Einstein Toolkit 08 Aug '12

08 Aug '12

#903: Build of Mojave Project fails ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: sbrandt Type: defect | Status: new Priority: major | Milestone: Cactus_4.1.0 Component: Mojave | Version: development version Keywords: | ---------------------+------------------------------------------------------ After creating a fresh Mojave project checkout and applying the NoThornIs9.patch files (see #768) I get this error when I try to build. java.lang.NullPointerException at edu.lsu.cct.mojave.IncludePathConfiguration.createIncludes(IncludePathConfiguration.java:215) at edu.lsu.cct.mojave.IncludePathConfiguration.SetIncludePath(IncludePathConfiguration.java:119) at edu.lsu.cct.mojave.DynamicMenu$3.widgetSelected(DynamicMenu.java:409) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:240) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3588) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3209) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/903> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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] #944: import outstanding Zelmani patches into ET trunk
by Einstein Toolkit 04 Aug '12

04 Aug '12

#944: import outstanding Zelmani patches into ET trunk -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- attached are all current outstanding differences between ET GRHydro and Zelmani GRHydro. I would like to flush them out into trunk. The only ones that do not work with current trunk are the Multirate ones (the last one) so those should be kept back until the MoL multirate issues are resolved. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/944> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[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
...
10
11
12
13
14
15
16
17
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2012