Trac

trac@lists.einsteintoolkit.org

8708 discussions

[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] #696: SimFactory should allow the user to enable standard output for all processes
by Einstein Toolkit 12 Dec '11

12 Dec '11

#696: SimFactory should allow the user to enable standard output for all processes -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- I would like to submit a job which redirects standard output and error from all processes to files. This is achieved via a Cactus command-line argument. It is currently not possible to do this without modifying the run script and rebuilding the configuration. One option would be to provide an option to the submit command which enabled this, such as "--redirect-all". Another would be to allow --cactus-args. The latter could be used also to change the logging level, but maybe removes control from simfactory that would be nice to keep. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/696> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #692: PunctureTracker should not depend on CarpetRegrid2
by Einstein Toolkit 12 Dec '11

12 Dec '11

#692: PunctureTracker should not depend on CarpetRegrid2 -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: PunctureTracker | -----------------------------------+---------------------------------------- The PunctureTracker thorn tracks the locations of punctures in BH simulations and puts them into spherical surfaces. It also seems to have logic which interacts with CarpetRegrid2 to control the mesh refinement. This degree of coupling is not good - what if you wanted to use a different regridding thorn, or a different driver? What if you wanted to do a unigrid simulation? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/692> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

Re: [ET Trac] [Users] [Einstein Toolkit] #677: parameter default change in CarpetIOASCII
by Erik Schnetter 12 Dec '11

12 Dec '11

On Mon, Dec 12, 2011 at 4:25 AM, Luca Baiotti <baiotti(a)ile.osaka-u.ac.jp>wrote: > On 12/12/11 7:50 AM, Einstein Toolkit wrote: > > #677: parameter default change in CarpetIOASCII > > > ----------------------------------------+----------------------------------- > > Reporter: baiotti@… | Owner: eschnett > > Type: enhancement | Status: new > > Priority: optional | Milestone: > > Component: Carpet | Version: > > Resolution: | Keywords: CaroetIOASCII > parameter default > > > ----------------------------------------+----------------------------------- > > > > Comment (by eschnett): > > > > Luca, do you want to discuss this on the mailing list? This ticket > seems > > to be ignored, and the changing a default value should be done by > > consensus. > > Erik, I had originally asked on the mailing list, with the message > "questions on CarpetIOASCII" sent on 10 Oct 2011. > Yes, it can be difficult to gather momentum for some changes... In my experience, this means that most people don't care about the change, and that some people won't like it but don't speak up, and that overall no one expects the change to happen unless a few people speak up for it. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.cct.lsu.edu/~eschnett/

1 0

[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] #690: CarpetIOASCII modification causes tests to fail
by Einstein Toolkit 12 Dec '11

12 Dec '11

#690: CarpetIOASCII modification causes tests to fail --------------------------------------+------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: testsuites CarpetIOASCII | --------------------------------------+------------------------------------- The following changeset, changeset: 3377:2f2e12bdf05b tag: tip user: Erik Schnetter <schnetter(a)cct.lsu.edu> date: Tue Nov 15 11:59:53 2011 -0500 summary: CarpetIOASCII: Add new "compact" output format causes the default CarpetIOASCII output format to change. Specifically, {{{ # iteration 0 # refinement level 0 multigrid level 0 map 0 component 0 time level 0 # column format: 1:it 2:tl 3:rl 4:c 5:ml 6:ix 7:iy 8:iz 9:time 10:x 11:y 12:z 13:data 0 0 0 0 0 0 18 3 0 -0.473684210526316 0.0967741935483871 0 0 }}} becomes {{{ # iteration 0 time 0 # time level 0 # refinement level 0 multigrid level 0 map 0 component 0 # column format: 1:it 2:tl 3:rl 4:c 5:ml 6:ix 7:iy 8:iz 9:time 10:x 11:y 12:z 13:data 0 0 0 0 0 0 18 3 0 -0.473684210526316 0.0967741935483871 0 0 }}} This causes certain test cases (I think those which do not use IO::out_fileinfo = "none") to fail. The problem is not in the modification of the comment lines, whose content is ignored by the test mechanism, but in the addition of a blank line or a comment line (the "time level 0" in the above example). The test mechanism compares files line-by-line, and so becomes out of step if additional comment or blank lines are introduced. The attached patch modifies the test mechanism to completely ignore the presence of any blank or comment lines. With this patch, the tests bhns_eval, bhns_interp, checkpointML and recoverML now pass again. Is this solution acceptable? Should the test mechanism be modified in a different way? Or should CarpetIOASCII be modified to produce the old format? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/690> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #689: Tests which use ML_ADMConstraints need to have results regenerated
by Einstein Toolkit 12 Dec '11

12 Dec '11

#689: Tests which use ML_ADMConstraints need to have results regenerated -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: ML_ADMConstraints | -----------------------------------+---------------------------------------- The correction implemented in #671 causes tests which have the incorrect values in their output files to fail. These need to be regenerated. Waiting for other test failures to be understood before doing this, however. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/689> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac