Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1431: Issue with McLachlan and ADMBase::initial_shift
by Einstein Toolkit 04 Sep '13

04 Sep '13

#1431: Issue with McLachlan and ADMBase::initial_shift -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan | -----------------------------------+---------------------------------------- ADMBase provides the parameter ADMBase::initial_dtshift, which defaults to “none”. It allocates storage for the ADMBase::dtshift group if this variable is not equal to “none”. Hence, if you forget to set this parameter, you would expect not to get any storage, and your code will noisily fail if you try to access this group. However, ML_BSSN_Helper allocates storage for ADMBase::dtshift directly. So even if ADMBase::initial_dtshift is “none”, you still get storage for the variable, but it is never initialised, and you get NaNs in the evolution from the first iteration. Also, ADMBase's shift_state variable will still be 0, even though the shift has storage. One minimal solution would be for ML_BSSN_Helper to only allocate storage for this variable if ADMBase::initial_shift is not “none”. Would this be a good solution? There is probably a similar issue for dtlapse, but this is not required during BBH evolutions, so I haven't noticed it. I think it is possible for McLachlan to be used without storage for ADMBase::dtshift, since the initial data might not be coming from ADMBase. So an alternative solution of aborting during parameter check if initial_shift is none wouldn't be a good solution. Aside: the logic at the top of ML_BSSN_Helper/schedule.ccl and that in ADMBase/schedule.ccl can be simplified since recent versions of Cactus allow you to use a variable for the number of timelevels in a storage declaration. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1431> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1398: make evolution_method etc. parameters of ADMBase steerable
by Einstein Toolkit 25 Aug '13

25 Aug '13

#1398: make evolution_method etc. parameters of ADMBase steerable -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: ADMBase | -----------------------------------+---------------------------------------- this is occasionally useful to continue a run that started in Cowling approximation using a spacetime thorn (or the other way around, continue in cowling once the spacetime settles down to a stationary state). The attached patch makes all but the initial data parameters of admbase steerable on recovery. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1398> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1254: Simplify SimFactory's get-output-dir command
by Einstein Toolkit 19 Aug '13

19 Aug '13

#1254: Simplify SimFactory's get-output-dir command -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, sim get-output-dir returns: {{{ Simulation name: <simname> Output directory: <basedir>/<simname>/output-NNNN/<parbasename> }}} I think most uses of this command would be in shell scripts, where it would be easier to use if it only output the actual output directory. The first line is redundant, as the user has already specified the simulation name. Also, simfactory is appending the <parbasename>, and assuming that such a directory exists and contains some useful data. Without parsing the parameter file and duplicating cactus logic, it cannot know where the actual data is. I think simfactory should just give the output-0000 directory, and leave it up to the user to figure out where to find the data in there. The attached patch implements this change. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1254> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1428: remove some Carpet build warnings, add run-time warnings about grid structure dataset
by Einstein Toolkit 18 Aug '13

18 Aug '13

#1428: remove some Carpet build warnings, add run-time warnings about grid structure dataset --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- the attached patch adds a level 2 warning when CarpetIOHDF5 cannot read the grid structure attribute (actually a dataset but treated as an attribute) in hdf5 files. This can happen if very old files (pre grid structure version 5) are being read or files that do not have the attribute at all. The attribute is used by the checkpoint recovery routine to reconstruct the process decomposition, but (as far as I know) ignored by the file reader for ID. There is also one bugfix in 0002 that makes it possible to read multipatch data into a cartesian simulation as ID by using only the cartesian patch. While the patch is fairly simple please comment on whether it is fine to move the calculation of upper/lower into the loop over local maps, given that the upper/lower values are those of the patch to be read from file. The reason for the move is that the calculation needs the stride which is read from the current simulation and not from the patch (and can only be gotten if the map in question actually exists). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1428> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1426: Fatal loopcontrol assertion causes 23 test failures
by Einstein Toolkit 15 Aug '13

15 Aug '13

#1426: Fatal loopcontrol assertion causes 23 test failures ----------------------+----------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: critical | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- A recent change has caused 23 of the tests to start failing: https://build.barrywardell.net/job/EinsteinToolkit/786/testReport/ One of the error messages is: {{{ /home/jenkins/workspace/EinsteinToolkit/arrangements/Carpet/LoopControl/src/loopcontrol.cc:795: void lc_control_init(lc_control_t*, lc_descr_t*, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t): Assertion `int(lc_fine_thread_comm.size()) < get_num_coarse_threads()' failed.cactus_sim: /home/jenkins/workspace/EinsteinToolkit/arrangements/Carpet/LoopControl/src/loopcontrol.cc:795: void lc_control_init(lc_control_t*, lc_descr_t*, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t, ptrdiff_t): Assertion `int(lc_fine_thread_comm.size()) < get_num_coarse_threads()' failed. }}} Many others are similar. I assume that this affects non-test runs as well. The test system has been offline since 6th August due to server maintenance, so the error was introduced sometime between 6th and 15th August. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1426> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1427: Poloidal magnentic field warning should be output at run time, not at compile time
by Einstein Toolkit 15 Aug '13

15 Aug '13

#1427: Poloidal magnentic field warning should be output at run time, not at compile time -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The warning /home/jenkins/workspace/EinsteinToolkit/arrangements/EinsteinInitialData/GRHydro_InitData/src/GRHydro_PoloidalMagFieldM.F90:110:2: warning: #warning "This algorithm does only work on Cartesian grids!!" [-Wcpp] should probably be output at run time, not only at compile time. (Of course, it would be even better if the code looked at the grid structure to determine whether the grid is Cartesian.) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1427> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1421: GetComponents shows uninitialized variable due to typo
by Einstein Toolkit 13 Aug '13

13 Aug '13

#1421: GetComponents shows uninitialized variable due to typo ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: GetComponents | Version: ET_2013_05 Keywords: ET_2013_05 | ---------------------------+------------------------------------------------ When trying to update from an existing checkout I got: {{{ Use of uninitialized value $, in concatenation (.) or string at /home/knarf/bin/GetComponents line 1632, <STDIN> line 1. }}} This is caused by a typo (an additional "$") in the script. However, I found that one of the arguments in the relevant comparison also needs a 'chomp' to compre successfully, which I also added in the attached patch that I propose to also apply to the last release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1421> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #605: Simfactory does not find the right 'path' for symlinked cactus directories
by Einstein Toolkit 13 Aug '13

13 Aug '13

#605: Simfactory does not find the right 'path' for symlinked cactus directories ------------------------+--------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: ET_2011_10 Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- Simfactory currently does not detect the 'right' path to a Cactus sourcetree if this is from within a symlink, e.g. Cactus -> /mnt/data/Cactus. This is because while `pwd` returns '/home/user/Cactus', simfactory uses a wrapper to the C-library getcwd(), which dereferences symlinks. Simfactory then gets '/mnt/data/Cactus' and tries to use this path on remote machines when syncing - which of course does not work. The attached patch fixes this by using os.environ.get("PWD") and, if this is not defined, using os.getcwd() as workaround. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/605> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #1415: GRHydro updates
by Einstein Toolkit 13 Aug '13

13 Aug '13

#1415: GRHydro updates -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- accumulated GRHydro changes since before the CGWAS school (July 22nd). Includes the PPM changes from the workshop. Does not yet include the staggered vector potential work since this seems to be still in early stages. Will commit after Thursday unless objections are raised. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1415> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #1422: Subscribing to commit notifications for the ET should be made easier
by Einstein Toolkit 13 Aug '13

13 Aug '13

#1422: Subscribing to commit notifications for the ET should be made easier -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- At the moment, if you want to receive commit notification emails about changes to components of the ET, you have to subscribe to a number of separate mailing lists. There is a "commits" mailing list for the ET, but this currently only includes notifications for components which are not announced on other lists. I propose that subscribing to the ET "commits" mailing list should be enough to receive commit notifications for all components in the toolkit, so that only one subscription is needed. This will also simplify mail filtering on the receiving end. Note that the individual components could continue to manage their own mailing lists if needed, but a copy of the commit notification would be sent to the ET commits list. The components with separate lists that I currently know about are: * SimFactory * Cactus * AEIThorns * Kranc * LSUThorns Probably the easiest way to implement this would be to modify the VC commit hooks to send the notification to the ET commits list in addition to wherever it is currently being sent. The commits list may have to be configured to accept email from these additional addresses. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1422> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac