#1473: Carpet segfaults in Shutdown
--------------------+-------------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
For high numbers of threads, Carpet segfaults in Shutdown for the
testsuite CarpetWaveToyNewRecover_test_1proc. I tried this with gcc and
intel on a Debian system. The machine I run this on (spine, with the
default simfactory configurations) has 2 processors with 8 cores, and ht
enabled. When I run this testsuite with 1 mpi process but certain numbers
of threads (e.g. 9, 11, 16) I see this segfault. Which number triggers the
bug seems to depend on the compiler, but seems to be consistent within
tries.
The backtrace I see is, e.g.,:
{{{
1. CarpetLib::signal_handler(int)
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN9CarpetLib14signal_handlerEi+0xeb)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/backtrace.cc:542]
2. /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [??:0]
3. /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [??:0]
4. /lib/x86_64-linux-gnu/libc.so.6(abort+0x180) [??:0]
5. /lib/x86_64-linux-gnu/libc.so.6(+0x6d52b) [??:0]
6. /lib/x86_64-linux-gnu/libc.so.6(+0x76d76) [??:0]
7. /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c) [??:0]
8. mem<double>::~mem()
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN3memIdED1Ev+0x80)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/mem.cc:185]
9. data<double>::free()
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN4dataIdE4freeEv+0x4b)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/data.cc:549]
a. data<double>::~data()
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN4dataIdED1Ev+0x27)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/data.cc:487]
b. data<double>::~data()
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN4dataIdED0Ev+0x9)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/data.cc:487]
c. ggf::recompose_free(int)
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN3ggf14recompose_freeEi+0x1ae)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/ggf.cc:257]
d. ggf::~ggf() [/home/knarf/ET_2013_11/exe/cactus_sim(_ZN3ggfD1Ev+0xde)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/ggf.cc:70]
e. gf<double>::~gf()
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN2gfIdED0Ev+0x9)
[/home/knarf/ET_2013_11/configs/sim/build/CarpetLib/gf.cc:30]
f. Carpet::Shutdown(tFleshConfig*)
[/home/knarf/ET_2013_11/exe/cactus_sim(_ZN6Carpet8ShutdownEP12tFleshConfig+0x3ad)
[/home/knarf/ET_2013_11/configs/sim/build/Carpet/Shutdown.cc:102]
10. /home/knarf/ET_2013_11/exe/cactus_sim(main+0x49)
[/home/knarf/ET_2013_11/configs/sim/build/Cactus/main/flesh.cc:92]
11. /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [??:0]
12. /home/knarf/ET_2013_11/exe/cactus_sim() [??:0]
}}}
Marking as minor because this is in Shutdown, however if something would
actually check for this it might break workflows.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1473>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#590: McLachlan should allow other thorns to set the gauge
-----------------------------------+----------------------------------------
Reporter: bmundim | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
The parameters lapse_evolution_method and shift_evolution_method are
usually set to ML_BSSN in McLachlan. However they are never checked
in the code. McLachlan indeed seems to ignore their values and
overwrite whatever the values of lapse or shift set elsewhere,
preventing therefore other thorns from setting them differently.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/590>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1495: Hopper doesn't pass test suite
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version: development version
Keywords: |
------------------------+---------------------------------------------------
There are many test suite failures on Hopper.
The problem seems to be MPI errors when running on multiple nodes. I do
not understand what is going wrong. I suspect a problem with our build or
run options. I have asked NERSC for help.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1495>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1340: simfactory does not abort --testsuite submission process if rsync fails
------------------------+---------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
when setting up testsuite runs simfactory uses rsync to copy the test
suite data into the simulation folder. If this rsync fails (eg. because a
user specified incorrect rsyncopts in defs.local.ini) the submission
process does not abort and instead submits an emtpy test-suite run.
{{{
rhaas@kraken-gsi2:~/ET_trunk> sim create-submit 2p6t --procs 12 --num-
threads 6 --walltime 4:0:0 --tests
uite --allocation TG-ASC120003
Skeleton Created
Job directory: "/lustre/scratch/rhaas/simulations/2p6t"
Option --testsuite given
Executable: "/nics/c/home/rhaas/ET_trunk/exe/cactus_sim"
Option list:
"/lustre/scratch/rhaas/simulations/2p6t/SIMFACTORY/cfg/OptionList"
Submit script:
"/lustre/scratch/rhaas/simulations/2p6t/SIMFACTORY/run/SubmitScript"
Run script:
"/lustre/scratch/rhaas/simulations/2p6t/SIMFACTORY/run/RunScript"
Assigned restart id: 0
Copying testsuite data
rsync: --times=no: option does not take an argument
rsync error: syntax or usage error (code 1) at main.c(1435) [client=3.0.9]
Executing submit command: /opt/torque/2.5.7/bin/qsub
/lustre/scratch/rhaas/simulations/2p6t/output-0000/SIMFACTORY/SubmitScript
Submit finished, job id is 3236567.nid00016
rhaas@kraken-gsi2:~/ET_trunk> qdel 3236567.nid00016
}}}
My rsynopts were:
{{{
rsyncopts = --times=no --checksum --include 'configs/*/ThornList'
--exclude 'configs/*/*'
}}}
which are bad for two reasons:
1.) kraken's rsync does not no --times-no (likely wants --notimes or so)
2.) --exclude 'configs/*/*' excludes cctk_MPI.h which is used by the test
suite infrastructure to detect the presence of MPI
Note that some of these options are obviously obsolete now that simfactory
defaults to --times=no --checksum anyway.
Still, simfactory should always check the exit status of any command it
calls I think.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1340>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1359: add "read from file" option ot HydroBase's initial_data options
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: HydroBase |
-----------------------------------+----------------------------------------
the attached patch adds a value "read from file" to HydroBase's
initial_XXX options. This makes it possible to use IOUtils file reader
with hydro data.
This is somewhat similar to IDFileADM's extension of ADMBase's options,
only we do not have to set any grid scalars.
Needed to be able to reproduce the MHD paper's collapse test since
Whisky_RNSID is not public.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1359>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1215: Source browsing not working
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
The repositories in the "Browse source" TRAC interface
(https://trac.einsteintoolkit.org/browser) are not being updated. The
last Cactus flesh commit visible there is from 10 months ago.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1215>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1493: testsuite Carpet/outer-buffers fails
--------------------+-------------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone: ET_2014_05
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The testsuite Carpet/outer-buffers fails because it sets the parameter
Carpet::use_outer_buffer_zones which doesn't exist anymore.
This testsuite was not usually run because a required thorn wasn't part of
the toolkit. This now changed, triggering a failure in the regular builds
and tests.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1493>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#849: Drop explicit support for Fortran 77 in Cactus
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77
is, for all practical purposes, a subset of Fortran 90, and thus Fortran
77 code can be compiled by Fortran 90 compilers.
There is currently no platform that has a Fortran 77 and no Fortran 90
compiler, and there is no Fortran source code in Cactus that cannot be
compiled by a Fortran 90 compiler.
In a way, supporting Fortran 77 as language is similar to supporting K&R C
as a language. We don't do this either.
I suggest to remove/ignore all configuration options regarding Fortran 77,
and to compile .f77 and .F77 files with a Fortran 90 compiler. This change
will simplify the configuration stage of Cactus. I don't expect any user
to notice.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/849>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#882: Create ThornGuideHTML target
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Barry Wardell suggests: The only issue is that there doesn't seem to be a
HTML version of the configuration specific ThornGuide make target, so we
should add this as a target at the same time as removing the patch. I'd
imagine this would just be a matter of copy-and-paste from the existing
ThornGuideHTML target.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/882>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1489: EinsteinExact (the arrangement) fails to build ThornGuideHTML
-----------------------------------+----------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2014_05
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
EinsteinExact (the arrangement) fails to build ThornGuideHTML. The problem
is the file spacetimes.tex which is included, but ThornGuideHTML is built
outside of the doc directory, and cannot find it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1489>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit