Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #476: GRHydro test suite failures (the ones using McLachlan)
by Einstein Toolkit 14 Aug '11

14 Aug '11

#476: GRHydro test suite failures (the ones using McLachlan) -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Hi, I am facing the following problems with the GRHydro test suites that uses McLachlan: INFO (GenericFD): The stencil for ML_BSSN_O2_convertFromADMBaseGamma requires 2 points, but the lower y boundary has only 1 points. INFO (GenericFD): The stencil for ML_BSSN_O2_convertFromADMBaseGamma requires 2 points, but the upper y boundary has only 1 points. any ideas of a simple fix? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/476> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 3

[Einstein Toolkit] #498: McLachlan doesn't check metric_type
by Einstein Toolkit 14 Aug '11

14 Aug '11

#498: McLachlan doesn't check metric_type -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- McLachlan doesn't check the metric type, which needs to be "physical". A static conformal factor is not supported. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/498> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #487: SimFactory should allow steering of parameters between restarts
by Einstein Toolkit 14 Aug '11

14 Aug '11

#487: SimFactory should allow steering of parameters between restarts -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- sim create currently takes the --parfile option, and this parfile is used for every restart. Cactus allows parameters to change upon recovery - this is called parameter steering. SimFactory should allow this as well. The obvious implementation is to allow a --parfile option to "sim submit" which uses the new parameter file in this and all subsequent restarts. This needs some code to be moved from restart.create to restart.submit regarding parameter file substitutions. We also need to decide what should happen to the copy of the parameter file stored in the top-level SIMFACTORY directory. Should it remain the same, or should it be updated with the new parameter file. Subsequent restarts should inherit the parameter file from the previous restart. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/487> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #446: 1D HDF5 output nonfunctional with multipatch - std::out_of_range
by Einstein Toolkit 14 Aug '11

14 Aug '11

#446: 1D HDF5 output nonfunctional with multipatch - std::out_of_range --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- I have tried to run the Llama/LlamaWaveToy/par/Kerr-Schild_Gaussian.par parameter file with the Mercurial version of Carpet. I get the error: terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check This does not happen with the Git version of Carpet. The backtrace is Backtrace from rank 0 pid 25881: 1. /lib64/libc.so.6(gsignal+0x35) [0x2b35dfd24265] 2. /lib64/libc.so.6(abort+0x110) [0x2b35dfd25d10] 3. __gnu_cxx::__verbose_terminate_handler()(/usr/lib64/libstdc++.so.6) 4. /usr/lib64/libstdc++.so.6 [0x2b35df69ddb6] 5. /usr/lib64/libstdc++.so.6 [0x2b35df69dde3] 6. /usr/lib64/libstdc++.so.6 [0x2b35df69deca] 7. std::__throw_out_of_range(char const*)(/usr/lib64/libstdc++.so.6) 8. CarpetIOHDF5::GetAllActive(dh const*, gh const*, int, int, bboxset<int, 3>&)(./SIMFACTORY/cactus_hg_datura) 9. CarpetIOHDF5::IOHDF5<1>::OutputDirection(_cGH const*, int, std::string, std::string, vect<int, 1> const&, bool, bool)(./SIMFACTORY/cactus_h g_datura) a. CarpetIOHDF5::IOHDF5<1>::OutputVarAs(_cGH const*, char const*, char const*)(./SIMFACTORY/cactus_hg_datura) b. CarpetIOHDF5::IOHDF5<1>::OutputGH(_cGH const*)(./SIMFACTORY/cactus_hg_datura) c. Carpet::OutputGH(_cGH const*)(./SIMFACTORY/cactus_hg_datura) d. ./SIMFACTORY/cactus_hg_datura [0x128ddeb] e. Carpet::Initialise(tFleshConfig*)(./SIMFACTORY/cactus_hg_datura) f. ./SIMFACTORY/cactus_hg_datura(main+0x99) [0x4d5649] 10. /lib64/libc.so.6(__libc_start_main+0xf4) [0x2b35dfd11994] 11. ./SIMFACTORY/cactus_hg_datura [0x4d5369] -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/446> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #497: Cannot recover a moved simulation
by Einstein Toolkit 11 Aug '11

11 Aug '11

#497: Cannot recover a moved simulation ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I recently had to move a simulation from one filesystem to another. It would not recover because the SIMFACTORY/properties.ini file uses absolute paths. I think that simulations should use relative paths (when the file is within the simulation) so that they can be considered as self-contained entities which can be moved from place to place. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/497> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #317: Unproper bevaviour of sim submit when changing the parfile
by Einstein Toolkit 09 Aug '11

09 Aug '11

#317: Unproper bevaviour of sim submit when changing the parfile ----------------------------------------------+----------------------------- Reporter: alexander.beck-ratzka@… | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: ET_2010_11 Keywords: | ----------------------------------------------+----------------------------- If I make changes to the parfile of my simulation, and call then simfactory submit with the option --parfile=newpar, simfactory does not take this parfile. Instead of this, simfactory uses an old parfile from the old output-xxxx directory in my simualations direrctory. This usage of the old parfile might be wished. However, if this is the case, simfactory must complain if invoked with the option "parfile=...". But simfactory does not complain. In my case, the parfile has been modfied, but I am using the same name. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/317> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #370: New TRAC status "please commit"
by Einstein Toolkit 09 Aug '11

09 Aug '11

#370: New TRAC status "please commit" ----------------------------------+----------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- We seem to have tickets stuck in the "review" stage that effectively have been reviewed, but have not been applied yet. We may want to introduce a new status for that. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/370> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #486: New TRAC status "confirmed"
by Einstein Toolkit 09 Aug '11

09 Aug '11

#486: New TRAC status "confirmed" ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- It would be useful to have a new TRAC status for tickets "confirmed" which would be used between "new" and "accepted" to indicate that the ticket is valid and the issue can be reproduced. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/486> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #123: Run a syntax checker in a pre-commit hook
by Einstein Toolkit 09 Aug '11

09 Aug '11

#123: Run a syntax checker in a pre-commit hook ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I am getting annoyed by the frequent syntax errors in SimFactory that used to be caught by Perl and are now not caught by Python. It would be ideal if syntax checking could be built into SimFactory, so that it executes automatically during startup if that isn't too slow. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/123> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #124: Implement a testing mechanism for simfactory
by Einstein Toolkit 09 Aug '11

09 Aug '11

#124: Implement a testing mechanism for simfactory -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Currently there is no easy way to check that a change to simfactory hasn't broken critical functionality. A system could be introduced to run through each command and check that it does the right thing. It won't be possible to check every single combination of possible options, but the most commonly used options should be tested. A first attempt could involve testing that the commands work locally on the current machine. This would involve submitting jobs and testing that they have the expected behaviour. On busy machines, this means that the tests could potentially take a long time to complete. Remote submission could be tested by running these tests from a central location (e.g. the developer's workstation or laptop). We could also include a python correctness checking step in these tests (e.g. using pychecker or pylint). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/124> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011