Trac November 2011

trac@lists.einsteintoolkit.org

2 participants
166 discussions

[Einstein Toolkit] #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices
by Einstein Toolkit 20 Dec '11

20 Dec '11

#66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices ----------------------------------+----------------------------------------- Reporter: bcmsma@… | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | ----------------------------------+----------------------------------------- While the assigned values for the parameters IOASCII::output_symmetry_points = "no" IOASCII::out3D_ghosts = "no" IOASCII::out3D_outer_ghosts = "no" work as intended when CarpetIOASCII is active, it doesn't work for CarpetIOHDF5: IOHDF5::out3D_ghosts = "no" IOHDF5::out3D_outer_ghosts = "no" IOHDF5::output_symmetry_points = "no" It doesn't do anything to the 3D data but it corrupts the 2D data slices while chopping out those regions. It would be nice to have them working for IOHDF5 method, specially when visualising Pi symmetric data. Note also that this report is for git version of Carpet. These parameters seem to become deprecated for the hg version. Does anyone use them regularly? Any substitute in mind? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/66> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #527: Thorn Dissipation should have 9th order dissipation added
by Einstein Toolkit 16 Dec '11

16 Dec '11

#527: Thorn Dissipation should have 9th order dissipation added -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Dissipation | -----------------------------------+---------------------------------------- The current standard in BBH evolutions is to use 8th order accurate finite differencing with 9th order accurate dissipation. Thorn Dissipation currently only supports up to 7th order accurate dissipation, and should be extended to support 9th order. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/527> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #678: Don't output build details for external libraries
by Einstein Toolkit 15 Dec '11

15 Dec '11

#678: Don't output build details for external libraries -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- When an external library is built, Cactus always outputs all details of the build process. Much of this should be suppressed (in particular checking whether to build the library) unless VERBOSE is set. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/678> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #578: Vectorize WeylScal4
by Einstein Toolkit 13 Dec '11

13 Dec '11

#578: Vectorize WeylScal4 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Set UseVectors->True in WeylScal4. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/578> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #657: Problems to checkout carpet (maxwell release) on ranger
by Einstein Toolkit 12 Dec '11

12 Dec '11

#657: Problems to checkout carpet (maxwell release) on ranger ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ Hi, I am facing a problem to checkout carpet on ranger: Warning: Could not checkout Carpet/doc, unable to switch to branch ET_2011_10. Any existing symlinks to Carpet/doc will be broken. this has repeated over different days and times. I am wondering if GetComponents is using a particular mercurial option that it is not present in the version installed on ranger, the 0.9.5 one, in order to switch mercurial branches. Please let me know if you face the same problem. Thanks. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/657> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #597: WeylScal4 should use the kranc script rather than calling Mathematica directly
by Einstein Toolkit 12 Dec '11

12 Dec '11

#597: WeylScal4 should use the kranc script rather than calling Mathematica directly -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: WeylScal4 testsuite | -----------------------------------+---------------------------------------- The attached patch makes WeylScal4 use the "kranc" script rather than calling Mathematica directly. This enables all the error-detection provided by Kranc and leads to tidier output. This patch can either be committed now or after the release. The files it touches are not used during use of WeylScal4, only during generation. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/597> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #645: Error concerning missing -V option when submitting job on LoneStar
by Einstein Toolkit 12 Dec '11

12 Dec '11

#645: Error concerning missing -V option when submitting job on LoneStar ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2011_10 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I used the following command to submit an ET testsuite job on LoneStar. The intention is to run on 1 process with 6 threads. sim --remote lonestar create-submit maxwell_1proc_2 --testsuite --procs 6 --num-threads 6 --walltime 4:00:00 --ppn-used 6 and got a weird error. SimFactory didn't report any error or return a nonzero exit code, even though it was unable to determine a job ID. I repeated the submission, and the second time it worked, so the fault appears to be intermittent. There was no difference in the submit script in each case, apart from the job name. The log file is attached, but the final error message from the log file is: {{{ [LOG:2011-10-22 11:29:05] self.submit(submitScript)::Executing submission command: qsub /scratch/00915/hinder/simulations/maxwell_1proc/output-0000/SIMFACTORY/SubmitScript [LOG:2011-10-22 11:29:05] self.makeActive()::Simulation maxwell_1proc with restart-id 0 has been made active [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::received raw output: Unable to run job: JSV rejected job. [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::Exiting. [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::----------------------------------------------------------------- [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::-- Welcome to the Lonestar4 Westmere/QDR IB Linux Cluster -- [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::----------------------------------------------------------------- [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::--> Checking that you specified -V... [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::--------------------------> Rejecting job <-------------------------- [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::-V is now a required option. Please specify it in your submit script. [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::--------------------------------------------------------------------- [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output):: [LOG:2011-10-22 11:29:06] job_id = self.extractJobId(output)::using submitRegex: Your job (\d+) $.*?$ has been submitted [LOG:2011-10-22 11:29:06] self.submit(submitScript)::After searching raw output, it was determined that the job_id is: -1 [LOG:2011-10-22 11:29:06] self.submit(submitScript)::If this is -1, that means the regex did NOT match anything. No job_id means no control. }}} Full log.txt file is attached. The job was not submitted. The weird thing is that I do have -V in my submission script. The file /scratch/00915/hinder/simulations/maxwell_1proc/output-0000/SIMFACTORY/SubmitScript has {{{ #! /bin/bash #$ -A TG-MCA02N014 #$ -q normal #$ -r n #$ -l h_rt=4:00:00 #$ -pe 1way 12 #$ #$ -V #$ -N maxwell_1proc-0 #$ -M ian.hinder(a)aei.mpg.de #$ -m abe #$ -o /scratch/00915/hinder/simulations/maxwell_1proc/output-0000/maxwell_1proc.out #$ -e /scratch/00915/hinder/simulations/maxwell_1proc/output-0000/maxwell_1proc.err cd /work/00915/hinder/Cactus/EinsteinToolkit /work/00915/hinder/Cactus/EinsteinToolkit/simfactory/bin/sim run maxwell_1proc --machine=lonestar --restart-id=0 }}} Any ideas? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/645> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #635: Cactus should print the number of processes used when running tests
by Einstein Toolkit 11 Dec '11

11 Dec '11

#635: Cactus should print the number of processes used when running tests -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- When running a test suite, it is usually important to know how many MPI processes are being used, as this determines which tests are run. This information is not currently present in the summary.log file, and is not output to standard output either. This makes it hard to check that simfactory is actually running a test on the expected number of processes. The attached patch outputs the number of processes to these two places. OK to apply before the release? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/635> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #668: Cactus does not strictly enforce STEERABLE values
by Einstein Toolkit 11 Dec '11

11 Dec '11

#668: Cactus does not strictly enforce STEERABLE values --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Cactus currently checks for valid values of STEERABLE (parameters) by looking for a sub-string, not an exact match. This way, e.g., RECOVERY is treated like RECOVER. The attached patch fixes this. Apart from two private changes this doesn't affect public thorns (I compiled, but that list is long), and in case it does a clear error message is printed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/668> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #675: allow zero timelevels in STORAGE when timelevels are specified via parameter
by Einstein Toolkit 11 Dec '11

11 Dec '11

#675: allow zero timelevels in STORAGE when timelevels are specified via parameter -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- this allows to simply set timelevels=0 to turn off storage without having to put an "if(do_something || timelevels > 0)" into schedule.ccl files. It is also the only way to turn off storage inside of a GROUP of SCHEDULE statement based on a condition (other than scheduling the item twice, once with STORAGE, once without). More complicated conditions require either (I believe): a. the (ab)use of accumulors the way that GRHydro::GRHydro_hydro_excision works (only all "and" or all "or" supported I think) a. using undocumented behaviour and putting C code into schedule.ccl {{{ const int compound_condition = condition_a || condition_b ? 3 : 2 SCHEDULE { STORAGE foo[compound_condition] ... }}} c. allow more than just identifiers within the '[]" brackets of STORAGE (most likely one has to allow almost everything "{{{[^]]+}}}") then use C's "?" operator to build up the complicated expression Having 0 timelevels works trivially since eventually these STORAGE statements end up in CCTK_GroupStorageIncrease which allows 0 timelevels. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/675> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← Newer
1
...
9
10
11
12
13
14
15
16
17
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2011