Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1855: BitBucket pull requests for ET components should go to the tickets mailing list
by Einstein Toolkit 08 Feb '16

08 Feb '16

#1855: BitBucket pull requests for ET components should go to the tickets mailing list -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Server Infrastructure | Version: development version Keywords: | -----------------------------------+---------------------------------------- If someone creates a pull request in an repository hosting ET thorns, then there should be an email notification to the ET tickets mailing list, otherwise nobody will know that it has been made unless they are explicitly watching that repository. And there are a lot of repositories. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1855> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1676: Add CT_MultiLevel elliptic solver to the Einstein Toolkit
by Einstein Toolkit 08 Feb '16

08 Feb '16

#1676: Add CT_MultiLevel elliptic solver to the Einstein Toolkit -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- This elliptic solver (http://lists.einsteintoolkit.org/pipermail/users/2013-August/003174.html) is being used by more people now, and it would be good to have it in the toolkit. It has tests and documentation, and the author supports (though has not requested) inclusion (http://lists.einsteintoolkit.org/pipermail/users/2014-January/003425.html). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1676> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1847: FFTW3 fortran interface not working for system installation
by Einstein Toolkit 25 Jan '16

25 Jan '16

#1847: FFTW3 fortran interface not working for system installation ----------------------+----------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- The FFTW3 thorn is able to detect system installations, but does not add (for example) /usr/include as include path since it is a standard system include path (for C), and could collide with other libraries. This is correct. However, some system fftw3 libraries install the fftw3.f Fortran file also in /usr/include, and expect this to be in the include path for the Fortran compiler. This, however, is not the case for all compilers (since /usr/include is meant for C headers, not Fortran), i.e., for gfortran. This could be seen as bug in the fftw3 installation, but we should provide a workaround. Right now, the FFTW3 thorn does not always provide a working interface for Fortran. Other libraries have similar problems, so I wonder if we could provide a common workaround. We have to add these directories as -I flag to the Fortran compiler, but we must not add it to the C or C++ compilers. I don't see a good way to currently do this within Cactus. Am I right? If so: would it make sense to have Cactus look for a variable, i.e., FFTW3_FINC_DIRS, and to only add those for Fortran compilations? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1847> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1852: MoL: Add "RK2-central" scheme
by Einstein Toolkit 09 Jan '16

09 Jan '16

#1852: MoL: Add "RK2-central" scheme -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- This is an RK2 integrator where the first substep has size dt/2. See <https://bitbucket.org/cactuscode/cactusnumerical/pull-requests/6/mol- add-rk2-central-scheme/diff>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1852> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1848: madd not found
by Einstein Toolkit 16 Dec '15

16 Dec '15

#1848: madd not found ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ I get numerous errors of the form /home/sbrandt/cactus/CactusFW/arrangements/Carpet/CarpetLib/src/prolongate_3d_rf2.cc:249:26: error: ‘madd’ is not a member of ‘VP {aka vecprops<double>}’ when trying to compile on my laptop usign gcc 5.1.1 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1848> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1849: CarpetIOHDF5: fix check for old string datatype
by Einstein Toolkit 15 Dec '15

15 Dec '15

#1849: CarpetIOHDF5: fix check for old string datatype --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: hdf5 | --------------------+------------------------------------------------------- The current code contains a check for an old way the grid structure string was saved: as H5T_NATIVE_CHAR. This check test whether the type found in a (checkpoint) file is of that type. However, this fails if H5T_NATIVE_CHAR was different on the machine writing the checkpoint and the one restoring from it (e.g., big vs. little endian int8). Instead of checking if the saved type is of type H5T_NATIVE_CHAR, this patch checks for the new datatype being of class H5T_STRING. This change makes the two restore testsuites pass on big endian machines (the checkpoint file in the testsuite was written using the old mechanism, on a little endian machine). https://bitbucket.org/eschnett/carpet/pull- requests/8/fixed_string_check/diff I tested that this fixes the problems on the big endian machine, and that the testsuite also still works on a regular, little endian machine, for both an old and a new-style checkpoint. The two lines changed both look like this: {{{ - HDF5_ERROR(old_data = H5Tequal(datatype, H5T_NATIVE_CHAR)); + HDF5_ERROR(old_data = 0 == H5Tdetect_class(datatype, H5T_STRING)); }}} I am not sure about whether we should back-port this. It would be easy, as the change is very small, and I tested it, but I would like to have a separate "yes" for that. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1849> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1841: GRHydro tracers broken
by Einstein Toolkit 14 Dec '15

14 Dec '15

#1841: GRHydro tracers broken -----------------------------------+---------------------------------------- Reporter: I.Hawke@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- The GRHydro::GRHydro_tracers group is not registered as a constrained variable with MoL in GRHydro. This means that, in runs with insufficient conserved variables and other memory settings, the first step through the loop sets NaNs for the tracers: they then fail to update (or, at least, not correctly). To fix this, add register_constrained("GRHydro::GRHydro_tracers"); on or around line 143 of GRHydro_RegisterVars.cc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1841> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1845: remove fortran compiler option -m128bit-long-double from general option lists
by Einstein Toolkit 11 Dec '15

11 Dec '15

#1845: remove fortran compiler option -m128bit-long-double from general option lists ------------------------+--------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2016_05 Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- According to the documentation: {{{ -m96bit-long-double -m128bit-long-double These switches control the size of long double type. The i386 application binary interface specifies the size to be 96 bits, so -m96bit- long-double is the default in 32 bit mode. Modern architectures (Pentium and newer) would prefer long double to be aligned to an 8 or 16 byte boundary. In arrays or structures conforming to the ABI, this would not be possible. So specifying a -m128bit-long- double will align long double to a 16 byte boundary by padding the long double with an additional 32 bit zero. In the x86-64 compiler, -m128bit-long-double is the default choice as its ABI specifies that long double is to be aligned on 16 byte boundary. Notice that neither of these options enable any extra precision over the x87 standard of 80 bits for a long double. Warning: if you override the default value for your target ABI, the structures and arrays containing long double variables will change their size as well as function calling convention for function taking long double will be modified. Hence they will not be binary compatible with arrays or structures in code compiled without that switch. }}} The problem with this switch is that it is target-specific; it is only defined for Intel platforms. Option lists like 'debian.cfg' should not be target specific. I don't know why this flag was given, and from above docu I can only imagine it is to preserve binary-compatibility between 32bit and 64bit long doubles. On the other hand, I have no idea how that plays out with linked libraries that might have been compiled differently, and also I have no idea where we would actually use Fortran long doubles. Thus, I here propose to remove this flag, at least from general option lists (not machine-specific), unless of course someone objects and can name a good reason to keep it. Currently it prevents option lists like debian.cfg or ubuntu.cfg from compiling on non-Intel platforms. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1845> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1846: Very large grids with bboxset2
by Einstein Toolkit 10 Dec '15

10 Dec '15

#1846: Very large grids with bboxset2 --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- Using the ET_2015_11 release, Carpet incorrectly replaces sets of components with their containing bbox, leading to a large increase in the number of grid points on the corresponding refinement level. This reduces simulation speed and causes increased memory usage (a lot). Using the same parameter file, this problem is visible with ET_2015_11, but not with ET_2014_05. Setting CARPET_DISABLE_BBOXSET2, or setting CarpetRegrid2::min_fraction = 1, both work around the problem. The bboxset2 code was enabled between these two releases, so this points to a problem with the code in bboxset2 that is used to determine whether to use the containing box or not. I attach parameter files and grid structure visualisations which demonstrate the problem. The parameters files differ only in the use of min_fraction = 1, but the same change is observed if you compile with -DCARPET_DISABLE_BBOXSET2 in CPPFLAGS. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1846> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1844: Backslash quoting problem in IllinoisGRMHD
by Einstein Toolkit 02 Dec '15

02 Dec '15

#1844: Backslash quoting problem in IllinoisGRMHD -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- This line in IllinoisGRMHD uses an unquoted backslash; the backslash should be replace by "\\" (a double backslash): {{{ repos/wvuthorns/IllinoisGRMHD/schedule.ccl:101:} "Apply linear extrapolation BCs on A_{\mu}, so that BCs are flat on B^i." }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1844> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac