Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1896: Interp2Array
by Einstein Toolkit 23 May '16

23 May '16

#1896: Interp2Array -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2016_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Interp2Array contains parameters for 2D output that specifies the 2d size: array2d_npoints_[ij]. This works on one process. On multiple mpi processes, more output appears for, e.g., arrays2d[0]_y_[0].xg. I haven't looked into the cause, yet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1896> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #912: Use CACTUS_CONFIGS_DIR in Formaline
by Einstein Toolkit 23 May '16

23 May '16

#912: Use CACTUS_CONFIGS_DIR in Formaline -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Formaline assumes that configurations are stored in a "configs" subdirectory of $CCTK_HOME. Use $CACTUS_CONFIGS_DIR instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/912> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1893: Compile error in Carpet when CCTK_REAL is single
by Einstein Toolkit 23 May '16

23 May '16

#1893: Compile error in Carpet when CCTK_REAL is single --------------------------------+------------------------------------------- Reporter: koppel@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | --------------------------------+------------------------------------------- When Cactus is configured with REAL_PRECISION = 4 there is a compile error in CarpetLib due to a hardcoded double type. The attached patch fixes the problem. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1893> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1892: Compile error when _OPENMP not defined.
by Einstein Toolkit 19 May '16

19 May '16

#1892: Compile error when _OPENMP not defined. -----------------------+---------------------------------------------------- Reporter: anonymous | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | -----------------------+---------------------------------------------------- There is a compile error when _OPENMP is not defined. The following fixes it: {{{ diff --git a/CarpetLib/src/dist.hh b/CarpetLib/src/dist.hh index acc646d..a5ba5be 100644 --- a/CarpetLib/src/dist.hh +++ b/CarpetLib/src/dist.hh @@ -18,6 +18,7 @@ #else static inline int omp_get_max_threads() { return 1; } static inline int omp_get_thread_num() { return 0; } +static inline int omp_get_num_threads() { return 1; } #endif #include "defs.hh" }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1892> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1870: ET_2015_11_v0 of McLachlan does regenerate code for ca6fe74 "McLachlan_BSSN.m: Make evolveA steerable"
by Einstein Toolkit 19 May '16

19 May '16

#1870: ET_2015_11_v0 of McLachlan does regenerate code for ca6fe74 "McLachlan_BSSN.m: Make evolveA steerable" -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan backport | -----------------------------------+---------------------------------------- the release branch claims to make ML_BSSN::evolveA steerable but fails to actually do so in the generated code. Commit 0b38cba1f9ee9fce3f1ed2543295266efb86107e of McLachlan fixes this on master. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1870> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1595: Is {{{*)}}} allowed as upper boundary for a parameter range?
by Einstein Toolkit 19 May '16

19 May '16

#1595: Is {{{*)}}} allowed as upper boundary for a parameter range? ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I sometimes see these warnings when Cactus starts: {{{ WARNING[L1,P0] (Cactus): Invalid end of real-valued parameter range; range descriptor is "(0.0 : *)" (value is 1) }}} Presumably the warning depends on which thorns are active. This warning looks as if the syntax {{{*)}}} was accepted by the CST when parsing a param.ccl file, but was later not recognized by the flesh when checking a parameter value against this range. (The flesh uses HUGE_VAL as fallback, which happens to be correct in this case.) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1595> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 40

[Einstein Toolkit] #1891: Formaline: aborts if files are removed from repo
by Einstein Toolkit 18 May '16

18 May '16

#1891: Formaline: aborts if files are removed from repo -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Formaline aborts if files are removed from a git repo, trying to 'git add' that file, and failing because it is not present anymore. See https://build.barrywardell.net/job/EinsteinToolkit/769/console -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1891> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1890: formaline capture simfactory information
by Einstein Toolkit 17 May '16

17 May '16

#1890: formaline capture simfactory information --------------------------------------------+------------------------------- Reporter: jonah.maxwell.miller@… | Owner: eschnett Type: enhancement | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: formaline | --------------------------------------------+------------------------------- It would be nice if Formaline captured the machine description used by simfactory (i.e., properties.ini, optionlist, submitscript) for a simulation. This information would be convenient for reproducing the exact configuration on a machine later. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1890> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1872: test system does not detect extra lines in output files
by Einstein Toolkit 13 May '16

13 May '16

#1872: test system does not detect extra lines in output files -----------------------+---------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: critical | Milestone: ET_2016_11 Component: Cactus | Version: development version Keywords: testsuite | -----------------------+---------------------------------------------------- I accidentally removed some lines of output from the stored test suite data in git hash [https://bitbucket.org/eloisa/ctthorns/commits/79c5e0d32fb1e3d6b219d7b55211f… 79c5e0d32fb1e3d6b219d7b55211fa3c388f7268] of ctthorns in the files {{{CT_MultiLevel/test/constraints_spherical/*_norm_eqn?.asc}}}. Yet the test all passed. I have since restored the changed files. This I would consider quite serious since extra output lines should always cause the test to fail rather than being silently ignored. I am marking this as critical since it potentially renders the test suites useless when detecting changes. If we fell we can "document away" this then, it can be downgraded to "major". -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1872> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1888: HDF5 output causing termination with std::out_of_range error
by Einstein Toolkit 12 May '16

12 May '16

#1888: HDF5 output causing termination with std::out_of_range error ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: eschnett Type: defect | Status: new Priority: unset | Milestone: Component: Carpet | Version: development version Keywords: | ---------------------------+------------------------------------------------ I am getting an std::out_of_range error when I try to run a simulation with the latest development version of the Einstein Toolkit. Specifically, the error I am getting is: {{{ terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check }}} The backtrace provides more detailed information: {{{ Backtrace from rank 0 pid 3146: 1. CarpetLib::signal_handler(int) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN9CarpetLib14signal_handlerEi+0x8e) [0x12a24de]] 2. /lib64/libc.so.6(+0x32920) [0x2aaab2e53920] 3. /lib64/libc.so.6(gsignal+0x35) [0x2aaab2e53885] 4. /lib64/libc.so.6(abort+0x181) [0x2aaab2e54e61] 5. __gnu_cxx::__verbose_terminate_handler() [/usr/lib64/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x11d) [0x2aaab29698ad]] 6. /usr/lib64/libstdc++.so.6(+0x63986) [0x2aaab2967986] 7. /usr/lib64/libstdc++.so.6(+0x639b3) [0x2aaab29679b3] 8. /usr/lib64/libstdc++.so.6(+0x63bf3) [0x2aaab2967bf3] 9. std::__throw_out_of_range(char const*) [/usr/lib64/libstdc++.so.6(_ZSt20__throw_out_of_rangePKc+0x5d) [0x2aaab29b92cd]] a. CarpetIOHDF5::IOHDF5<1>::WriteHDF5(_cGH const*, int&, int&, std::vector<gdata*, std::allocator<gdata*> >, bbox<int, 3> const&, int, vect<int, 3> const&, vect<int, 1> const&, int, int, int, int , int, int, double, vect<double, 3> const&, vect<double, 3> const&) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE9WriteHDF5EPK4_cGHRiS 5_St6vectorIP5gdataSaIS8_EERK4bboxIiLi3EEiRK4vectIiLi3EERKSF_IiLi1EEiiiiiidRKSF_IdLi3EESO_+0x2516) [0x123d526]] b. CarpetIOHDF5::IOHDF5<1>::OutputDirection(_cGH const*, int, std::string, std::string, vect<int, 1> const&, bool, bool) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_si m(_ZN12CarpetIOHDF56IOHDF5ILi1EE15OutputDirectionEPK4_cGHiSsSsRK4vectIiLi1EEbb+0xf28) [0x1239378]] c. CarpetIOHDF5::IOHDF5<1>::OutputVarAs(_cGH const*, char const*, char const*) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE11OutputVa rAsEPK4_cGHPKcS6_+0x4a4) [0x1237004]] d. CarpetIOHDF5::IOHDF5<1>::TriggerOutput(_cGH const*, int) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE13TriggerOutputEPK4_cGHi+0x1b 3) [0x1236a23]] e. CarpetIOHDF5::IOHDF5<1>::OutputGH(_cGH const*) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE8OutputGHEPK4_cGH+0x368) [0x1236568]] f. Carpet::OutputGH(_cGH const*) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN6Carpet8OutputGHEPK4_cGH+0x6cb) [0x1136d1b]] 10. /ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim() [0x1132cf1] 11. Carpet::Initialise(tFleshConfig*) [/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN6Carpet10InitialiseEP12tFleshConfig+0x767) [0x1134b17]] 12. /ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(main+0x99) [0x3b2ed29] 13. /lib64/libc.so.6(__libc_start_main+0xe6) [0x2aaab2e3fc36] 14. /ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim() [0xd3a609] }}} This suggests the problem is in CarpetIOHDF5, and indeed reverting Carpet commit cf2e12631ed9b6e1eac95ae5f311fdbe5100db75 makes the problem go away. The parameter file I am using is this one: [https://bitbucket.org/simulationtools/simulationtoolstestdata/src/master/Si… bbh.par]. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1888> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac