Trac November 2011

trac@lists.einsteintoolkit.org

2 participants
166 discussions

[Einstein Toolkit] #520: TOVSolver test cases are failing
by Einstein Toolkit 10 Nov '11

10 Nov '11

#520: TOVSolver test cases are failing -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: TOVSolver testsuite | -----------------------------------+---------------------------------------- The TOVSolver test cases run on 08-Aug-2011 failed. http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/ The errors are related to nontrivial changes in the ADMBase variables: http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/einsteintoolk… This is likely related to changeset:"62/ADMBase" committed as a result of #333. User: hinder Date: 2011/08/17 05:07 PM Modified: /trunk/ interface.ccl /trunk/src/ InitSymBound.c Log: Apply "flat" boundary condition instead of "none" to ADMBase variables In the development version of Carpet, only the interior of the newly created grid is initialized by interpolation, so non-trivial boundary conditions need to be applied. I don't know whether the old or the new results are correct. The failure happens with both the stable and development versions of Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/520> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #496: WeylScal4 fails tests with development version of Carpet
by Einstein Toolkit 10 Nov '11

10 Nov '11

#496: WeylScal4 fails tests with development version of Carpet --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- Both WeylScal4 tests fail with the development version of Carpet but not with the stable version. The report is Psi4i.d.asc: substantial differences significant differences on 16 (out of 62) lines maximum absolute difference in column 13 is 0.0042979716483804 maximum relative difference in column 13 is 0.221177389498685 (insignificant differences on 20 lines) Psi4i.z.asc: substantial differences significant differences on 24 (out of 108) lines maximum absolute difference in column 13 is 0.0123048458581252 maximum relative difference in column 13 is 1.43992798290495 (insignificant differences on 54 lines) Psi4r.d.asc: substantial differences significant differences on 16 (out of 62) lines maximum absolute difference in column 13 is 2.99002416115686e-05 maximum relative difference in column 13 is 0.995857600242238 (insignificant differences on 26 lines) Psi4r.x.asc: substantial differences significant differences on 42 (out of 146) lines maximum absolute difference in column 13 is 0.0063512431519604 maximum relative difference in column 13 is 1.35438090371356 (insignificant differences on 84 lines) Psi4r.y.asc: substantial differences significant differences on 42 (out of 146) lines maximum absolute difference in column 13 is 0.0064343032695815 maximum relative difference in column 13 is 1.1458862046889 (insignificant differences on 84 lines) Psi4r.z.asc: substantial differences significant differences on 24 (out of 108) lines maximum absolute difference in column 13 is 0.00010846878486765 maximum relative difference in column 13 is 2.89015233246968 (insignificant differences on 64 lines) One possibility is that the grids in this test are so small that the grid structure is being affected by the Carpet regridding algorithm which ensures proper nesting, and this algorithm might have changed unavoidably between the stable and development versions of Carpet. If we confirm that this is the case, we could either use a larger grid to prevent this from happening, or just regenerate the data. It would be useful to add output of the coordinate gridfunctions to catch the cases where the grids are a different shape. (Reporting against Carpet so it can be fixed as part of the move to the development version) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/496> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #410: CarpetIOHDF5 may segfault when one_file_per_group is selected
by Einstein Toolkit 09 Nov '11

09 Nov '11

#410: CarpetIOHDF5 may segfault when one_file_per_group is selected --------------------------------+------------------------------------------- Reporter: bmundim | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: Carpet git version | --------------------------------+------------------------------------------- I was facing one of those cryptic MPI error messages on Ranger, where your job quits without any useful error message. It turns out that this parameter file had CarpetIOHDF5::one_file_per_group = "yes" CarpetIOHDF5::out2D_vars = " ADMBase::gxx" and CarpetIOHDF5 would try to loop over the group variables when just one of them was selected. As a result it has accessed memory address that it was not supposed to, consequently killing the job. I have attached the stack back trace. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/410> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #665: CarpetIO* output parameter format error
by Einstein Toolkit 09 Nov '11

09 Nov '11

#665: CarpetIO* output parameter format error ---------------------------------------+------------------------------------ Reporter: baiotti@… | Type: enhancement Status: new | Priority: minor Milestone: | Component: Cactus Version: | Keywords: syntax for variable names ---------------------------------------+------------------------------------ Even if it is an unofficial feature, the output parameter format for public variables, e.g.: IOASCII::out1D_vars = "THORN_NAME::VARIABLE_NAME" should be accepted. Instead, I found that when requesting output as IOASCII::out1D_vars = "TestOutput::testoutput" for a *public:* or *protected:* variable group of the type: CCTK_REAL testoutput[nvar] type=GF TimeLevels=1 Dim=3 { output } "" where nvar is an integer parameter and the thorn name is TestOutput and differs from the implementation name, Carpet complains that WARNING[L1,P0] (Cactus): CCTK_TraverseString: invalid group/variable name 'TestOutput::testoutput' in traversed string 'TestOutput::testoutput' WARNING level 0 in thorn IOUtil processor 0 host mbaiotti2-2.local (line 140 of /Users/baiotti/Cactus.fresh- checkout/arrangements/CactusBase/IOUtil/src/Utils.c): -> error while parsing parameter 'IOBasic::outInfo_vars' For *private:* arrays of variables it works. I attach an example thorn and parfile. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/665> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #431: Update some external libraries
by Einstein Toolkit 09 Nov '11

09 Nov '11

#431: Update some external libraries -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Several external libraries have new versions available: LAPACK PETSc curl git These are only minor updates. I suggest to apply them. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/431> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #467: Make table printing functions publicly accessible
by Einstein Toolkit 09 Nov '11

09 Nov '11

#467: Make table printing functions publicly accessible -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The table data types (util_Table.h) have internal routines that print the table contents to screen. This can be helpful for debugging. The attached patch makes these functions publicly available. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/467> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #532: Don't copy .svn directories when running test cases
by Einstein Toolkit 09 Nov '11

09 Nov '11

#532: Don't copy .svn directories when running test cases -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Don't copy .svn or .git directories when running test cases. We probably have a list of excluded directories somewhere that we could reuse. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/532> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #530: Change default for --num-threads
by Einstein Toolkit 09 Nov '11

09 Nov '11

#530: Change default for --num-threads -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Change the default for --num-threads to be what the MDB specifies for the particular machine, instead of using a single thread by default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/530> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #563: Do not copy .svn directories for test suite
by Einstein Toolkit 09 Nov '11

09 Nov '11

#563: Do not copy .svn directories for test suite ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Simfactory copies the content of .svn directories when it copies the test case data into the simulation directory. The problem is line 509 in simrestart.py; this rsync command doesn't exclude .svn directories. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/563> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #601: Wanted: Routine to convert table to string
by Einstein Toolkit 09 Nov '11

09 Nov '11

#601: Wanted: Routine to convert table to string -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to have a routine that converted a table to a string, using the same syntax that is accepted by Util_TableCreateFromString. This is a nice, compact notation that is much easier to read than the internal table dumping syntax. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/601> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2011