Trac April 2012

trac@lists.einsteintoolkit.org

1 participants
196 discussions

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

[Einstein Toolkit] #839: MoL Multirate capabilities. This add three new multirate RK schemes to MoL.
by Einstein Toolkit 02 Aug '12

02 Aug '12

#839: MoL Multirate capabilities. This add three new multirate RK schemes to MoL. ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: enhancement Status: new | Priority: optional Milestone: | Component: Cactus Version: | Keywords: MoL Multirate ----------------------------------------+----------------------------------- In order to make multirate work, we need to introduce new registration routines that explicitly register variables with the "slow" sector, i.e. those variables which are integrated by the lower order scheme. This also means that we require new "accumulator" parameters indicating how many "slow" variables we want to register. Flags indicate whether it is time to execute slow RHS computation. For instance, in the RK4-RK2 scheme, there are 4 substeps in total, but the RK2 RHS are only evaluated in the very first and in the very last step of the four substeps. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/839> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #550: CarpetIOHDF5 too verbose while reading from checkpoint
by Einstein Toolkit 02 Aug '12

02 Aug '12

#550: CarpetIOHDF5 too verbose while reading from checkpoint -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- It is not that uncommon that I recover using a different number of processors. Every time I do this I see the error file cluttered with messages like WARNING level 1 in thorn CarpetIOHDF5 processor 21 host c312-313.ls4.tacc.utexas.edu (line 640 of /work/00920/tg459479/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Input.cc): -> Variable AHFINDERDIRECT::ahmask on rl 0 and tl 0 not read completely. Will have to look for it in other files I expect this, this is not an error and not really something to warn about. I acknowledge that this might have been introduced when recovering using the same number of processors was a problem and caused reading all files, but I don't think this is an issue anymore. I propose to change the warnlevel for this message to CCTK_WARN_DEBUG(4). In addition it would be good to have _one_ separate message with level CCTK_WARN_PICKY(3) if any variable/reflevel/timelevel could not be read completely (but not one for each of these), ideally only once for all processors. This would not clutter the output of the default simfactory runs (-L 3) too much, but would indicate that this happened - and in case this is a problem it's easy to enable -L 4. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/550> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #634: Riemann1D fails to compile on Kraken
by Einstein Toolkit 08 Jul '12

08 Jul '12

#634: Riemann1D fails to compile on Kraken -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- I'm unable to compile the Riemann1D utility on Kraken. It gives the following error message. {{{ Creating Riemann1d in /nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim from /nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o /nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o: In function `riemann1d': /nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:10: undefined reference to `__kmpc_begin' /nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:374: undefined reference to `__kmpc_end' /usr/bin/ld: link errors found, deleting executable `/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d' make[1]: *** [/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d] Error 1 make: *** [sim-utils] Error 2 }}} I think that this needs an Intel library to be linked in, but I'm not sure which one or how to add it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/634> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #751: Carpet fails when running qc0-mclachlan.par
by Einstein Toolkit 08 Jul '12

08 Jul '12

#751: Carpet fails when running qc0-mclachlan.par --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- this is due to ggf::transfer_from_all line 613 (dst->transfer_from) where dst is NULL: {{{ 03 assert (lc1>=0 or lc2>=0); 604 605 // Source and destination data 606 gdata * const dst = 607 lc1>=0 ? storage.AT(ml1).AT(rl1).AT(lc1).AT(tl1) : NULL; 608 cdata const & srcs = srcstorage.AT(ml2).AT(rl2); 609 for (int i=0; i<(int)gsrcs.size(); ++i) { 610 gsrcs.AT(i) = lc2>=0 ? srcs.AT(lc2).AT(tl2s.AT(i)) : NULL; 611 } 612 613 dst->transfer_from 614 (state, gsrcs, times, recv, send, slabinfo, p1, p2, time, pos, pot); }}} which causes a segfault in line 613. lc1 is -1 in this case and passes the assert in line 603. Since dst is used as a pointer it may never be NULL. It can be reproduced with the qc0-mclachlan.par example from simfactory. Tested on Caltech's bethe workstation with 12 MPI processes and no OpenMP. hg blames commit 5418b354a3ab which seems to be the original Carpet import into mercurial so this seems to be caused by something else. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/751> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #813: Fix all thorns that attempt reductions in local mode
by Einstein Toolkit 06 Jul '12

06 Jul '12

#813: Fix all thorns that attempt reductions in local mode -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Recently these produce a level three warning (simfactorie's default) whenever they attempt to do so and clutter the log files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/813> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

← Newer
1
...
7
8
9
10
11
12
13
...
20
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2012