Trac August 2012

trac@lists.einsteintoolkit.org

1 participants
206 discussions

[Einstein Toolkit] #1000: mistake in Cactus documentation
by Einstein Toolkit 02 Aug '12

02 Aug '12

#1000: mistake in Cactus documentation -----------------------+---------------------------------------------------- Reporter: anonymous | Type: task Status: new | Priority: minor Milestone: | Component: Other Version: | Keywords: mistake in documentation -----------------------+---------------------------------------------------- Revision : 4846 A152/A271 of the ReferenceManual has a trivial mistake: when describing CCTK_LocalArrayReductionHandle it says: Synopsys int handle = CCTK_ReduceLocalArrays(const char *operator); -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1000> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #839: MoL Multirate capabilities. This add three new multirate RK schemes to MoL.
by Einstein Toolkit 02 Aug '12

02 Aug '12

#839: MoL Multirate capabilities. This add three new multirate RK schemes to MoL. ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: enhancement Status: new | Priority: optional Milestone: | Component: Cactus Version: | Keywords: MoL Multirate ----------------------------------------+----------------------------------- In order to make multirate work, we need to introduce new registration routines that explicitly register variables with the "slow" sector, i.e. those variables which are integrated by the lower order scheme. This also means that we require new "accumulator" parameters indicating how many "slow" variables we want to register. Flags indicate whether it is time to execute slow RHS computation. For instance, in the RK4-RK2 scheme, there are 4 substeps in total, but the RK2 RHS are only evaluated in the very first and in the very last step of the four substeps. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/839> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #550: CarpetIOHDF5 too verbose while reading from checkpoint
by Einstein Toolkit 02 Aug '12

02 Aug '12

#550: CarpetIOHDF5 too verbose while reading from checkpoint -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- It is not that uncommon that I recover using a different number of processors. Every time I do this I see the error file cluttered with messages like WARNING level 1 in thorn CarpetIOHDF5 processor 21 host c312-313.ls4.tacc.utexas.edu (line 640 of /work/00920/tg459479/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Input.cc): -> Variable AHFINDERDIRECT::ahmask on rl 0 and tl 0 not read completely. Will have to look for it in other files I expect this, this is not an error and not really something to warn about. I acknowledge that this might have been introduced when recovering using the same number of processors was a problem and caused reading all files, but I don't think this is an issue anymore. I propose to change the warnlevel for this message to CCTK_WARN_DEBUG(4). In addition it would be good to have _one_ separate message with level CCTK_WARN_PICKY(3) if any variable/reflevel/timelevel could not be read completely (but not one for each of these), ideally only once for all processors. This would not clutter the output of the default simfactory runs (-L 3) too much, but would indicate that this happened - and in case this is a problem it's easy to enable -L 4. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/550> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #996: change default values of PUGH's periodic parameters to "no"
by Einstein Toolkit 02 Aug '12

02 Aug '12

#996: change default values of PUGH's periodic parameters to "no" -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: PUGH | -----------------------------------+---------------------------------------- Right now the default values between Carpet and PUGH (who both implement) "Driver" differ (see #745). Since they should not (for reasons that it prevents users from easily switching from one to the other and because the current Cactus implementation has a bug when handling this case) and because Carpet (which does not even support periodic boundary conditions in this manner) is by far the more common driver in production simulations I would like to change the defaults. Users who actually use PUGH and use its periodic boundary condition without setting the periodic parameters please speak up. Ideally one would precede the change of defaults with an announcement to the mailing list and maybe even spread it over two ET releases. It should be done though (and #745 ought to be fixed). Otherwise other users might have to experience the joy of having to wait for a day for a test run on a busy cluster only to have it fail due to Carpet complaining about the periodic Parameters being set (since the debug executable had PUGH compiled in but the one to generate the checkpoints I was investigating had not). Fixing #745 would solve the problem of mysterious error messages aborting runs but would still leave two implementations with different default parameter values. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/996> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1001: Distinguish between local and global reduction handles
by Einstein Toolkit 02 Aug '12

02 Aug '12

#1001: Distinguish between local and global reduction handles -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Local and global reduction handles both use small integers. This means that code may accidentally confuse one for the other. To avoid this, we could add large, different offsets for local and global handles, so that they would be different. We already do this for other integer IDs in the flesh. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1001> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #999: .....
by Einstein Toolkit 01 Aug '12

01 Aug '12

#999: ..... --------------------------------------+------------------------------------- Reporter: permeduclo1976@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: key1,key2 --------------------------------------+------------------------------------- _, I like this site very much so much fantastic info . -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/999> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2012