#412: Split Appendices
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently, the appendices of the users' guide are repeated into the
reference manual. This is somewhat confusing, and causes problems because
the appendices cannot easily reference other sections (e.g. "see page 15"
doesn't make sense since one doesn't know in which document this will be
read). I suggest to split the appendices and have some of them in the
users' guide while moving others into the reference manual, so that each
appendix is included in only one document
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/412>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#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
#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
#350: Autogenerating cctk_Loop.h
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I wrote a perl script to auto-generate the Cactus header file
Cactus/src/include/cctk_Loop.h.The script writes the code to stdout. I
attach it to this ticket, as well as the output it generates.
I suggest to keep this perl script next to its output in the include
directory, and to run it manually whenever required.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/350>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#215: Driscoll&Healy integration for Multipole
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
The attached patch implements a more accurate integration over the sphere,
using an algorithm by Driscoll & Healy. This algorithm uses Gaussian
integration weights, leading (almost) to exponential convergence.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/215>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#429: Parallelising AEILocalInterp
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
The enclosed patch parallelises AEILocalInterp via OpenMP.
This leads to a slight change in behaviour. Currently, AEILocalInterp
traverses the list of points sequentially, and aborts when the first error
is encountered. After parallelisation, there is no fixed order in which
the points are traversed, and if several errors are encountered, any one
of the errors may be returned, not necessarily the first. I am not aware
of any thorn that would or should rely on such an ordering.
This patch also adds "restrict" and "const" statements that may improve
performance as it gives the compiler more information about dependencies
between pointers.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/429>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit