Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[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] #916: GetComponents can't update Cactus
by Einstein Toolkit 10 Aug '12

10 Aug '12

#916: GetComponents can't update Cactus ---------------------------+------------------------------------------------ Reporter: sbrandt | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Cactus_4.1.0 Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ Files as simple as !DEFINE ROOT = Cactus !DEFINE ARR = $ROOT/arrangements # Cactus Flesh !TARGET = $ROOT !TYPE = svn !AUTH_URL = https://svn.cactuscode.org/flesh/trunk !URL = http://svn.cactuscode.org/flesh/trunk !CHECKOUT = Cactus !NAME = . fail because of trailing whitespace. In particular, all the whitespace on lines following the !NAME line get absorbed so that . becomes .+ws (where ws contains spaces and newlines). This affects the main ET checkout. Patch: 397a398,400 > for my $pairs (@pairs) { > $pairs =~ s/\s+$//; > } -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/916> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[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] #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

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2012