Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #276: cleanup is not inhibited after errors
by Einstein Toolkit 10 Feb '11

10 Feb '11

#276: cleanup is not inhibited after errors ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- SimFactory should detect if qsub or qstat failed, or if the corresponding patterns didn't match. In this case, there should be an error message alerting the user. In this case, cleanup should not automatically clean up the simulations, since it cannot detect whether the restarts are finished. ("cleanup --force" should probably still work.) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/276> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #149: BVec in HydroBase/interface.ccl should be an axial vector
by Einstein Toolkit 09 Feb '11

09 Feb '11

#149: BVec in HydroBase/interface.ccl should be an axial vector --------------------------------------------+------------------------------- Reporter: roland.haas@… | Type: defect Status: new | Priority: major Milestone: | Component: Cactus Version: | Keywords: --------------------------------------------+------------------------------- the magnetic field is a pseudovector so should have tensorparity=-1 in interface.ccl. CCTK_REAL Bvec[3] type = GF Timelevels = 3 tags='ProlongationParameter="HydroBase::prolongation_type" tensortypealias="U" tensorparity=-1 interpolator="matter"' "Magnetic field components B^i" Parities are used by the Reflection thorn. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/149> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #254: tensorparity=-1 quantities in ReflectionSymmetry
by Einstein Toolkit 09 Feb '11

09 Feb '11

#254: tensorparity=-1 quantities in ReflectionSymmetry --------------------------------------------+------------------------------- Reporter: roland.haas@… | Type: defect Status: new | Priority: major Milestone: | Component: Cactus Version: | Keywords: --------------------------------------------+------------------------------- I would like to suggest applying the attached patch to ReflectionSymmetry to fix (I believe) its handling of the tensorparity attribute. Explanation/Rationale: In ReflectionSymmetry/interpolate.c parities[dir] is set to the behaviour under reflection across the "dir"=0 plane of an object of type tensortypealis. It does not take tensorparity into account. Therefore check_dir[dir] must take tensorparity into account explicitly. The second change is "parity = 1" instead of "parity = tensorparity" which states that if a point is never reflected then the value that was on the grid is to be used as-is. I have tested these changes with the magnetic field created by a wire along the x,y,z axis and reflection across the various planes and with RotatingSymmetry180 and *90. Please see ticket #149 https://trac.einsteintoolkit.org/ticket/149 for sample parameter files and test scripts. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/254> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #272: GetComponents: use of uninitialized values.
by Einstein Toolkit 09 Feb '11

09 Feb '11

#272: GetComponents: use of uninitialized values. ----------------------------------+----------------------------------------- Reporter: bmundim | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: uninitialized values | ----------------------------------+----------------------------------------- Hi, I am receiving the following kind of messages when updating my tree with the newest version of GetComponents (./GetComponents -u -a --noshallow thorns.th): ----------------------------------------------------------------- Updating module: Carpet/doc from repository: git://carpetcode.dyndns.org/carpet located in: Cactus/arrangements Use of uninitialized value in regexp compilation at ./GetComponents line 1569. Use of uninitialized value in concatenation (.) or string at ./GetComponents line 1572. Use of uninitialized value in concatenation (.) or string at ./GetComponents line 1572. Already on 'master' ----------------------------------------------------------------- Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/272> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #261: GetComponents misleading warning message
by Einstein Toolkit 09 Feb '11

09 Feb '11

#261: GetComponents misleading warning message ------------------------------+--------------------------------------------- Reporter: bmundim | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: warning messages | ------------------------------+--------------------------------------------- I receive the following kind of warning quite often when updating my tree: ----------------------------------------------------------------- Updating module: Carpet/doc from repository: git://carpetcode.dyndns.org/carpet located in: Cactus/arrangements Executing: git stash In: /work/01157/bcmundim/einstein_dev_chandra/Cactus/repos/carpet No local changes to save Executing: git pull --rebase In: /work/01157/bcmundim/einstein_dev_chandra/Cactus/repos/carpet Current branch master is up to date. Executing: git stash pop In: /work/01157/bcmundim/einstein_dev_chandra/Cactus/repos/carpet fatal: Needed a single revision : no valid stashed state found Warning: Could not update carpet. Could not pop stashed changes. ----------------------------------------------------------------- I am not sure what 'fatal: Needed a single revision' means, but if the current branch is already up to date, why do I receive a warning message saying that GetComponents couldn't update the repository? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/261> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #248: Enhance GetComponents functionality when dealing with git branches
by Einstein Toolkit 09 Feb '11

09 Feb '11

#248: Enhance GetComponents functionality when dealing with git branches ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: git branches | ---------------------------+------------------------------------------------ When using git it is very common to develop new code or functionality in separate branches. Sometimes these branches are maintained in a central repository too (besides in the user local repo). It would be nice if GetComponents could handle the checkout and update of *all* these branches in the *same* Cactus tree. Currently we have to either checkout these branches manually (a bit inconvenient) or to have several Cactus trees, each containing the branch that we want to work with (quite impractical and expensive). I suggest that GetComponents understands the following lines written in the same thorn list file and checkout all the appropriate branches: !CRL_VERSION = 1.0 !DEFINE ROOT = Cactus !DEFINE ARR = $ROOT/arrangements # Checkout the master branch: !TARGET = $ARR !TYPE = git !URL = ssh://path/to/repo !CHECKOUT = arrangement1/thorn1 arrangement1/thorn2 #Checkout the development branch: !TARGET = $ARR !TYPE = git !URL = ssh://path/to/repo !REPO_BRANCH = development !CHECKOUT = arrangement1/thorn1 arrangement1/thorn2 #Checkout the experimental branch: !TARGET = $ARR !TYPE = git !URL = ssh://path/to/repo !REPO_BRANCH = experimental !CHECKOUT = arrangement1/thorn1 arrangement1/thorn2 #Checkout the test branch: !TARGET = $ARR !TYPE = git !URL = ssh://path/to/repo !REPO_BRANCH = test !CHECKOUT = arrangement1/thorn1 arrangement1/thorn2 As far as I understand this workflow is not usual for either cvs or svn. So the "feature" proposed here would be limited to git repositories (I know nothing about darcs and very little about hg. So someone may want to comment for these repo types.). Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/248> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #264: Reference Manual gives wrong include file for CCTK_TerminateNext
by Einstein Toolkit 07 Feb '11

07 Feb '11

#264: Reference Manual gives wrong include file for CCTK_TerminateNext --------------------------------------------+------------------------------- Reporter: roland.haas@… | Type: defect Status: new | Priority: minor Milestone: | Component: Cactus Version: | Keywords: documentation --------------------------------------------+------------------------------- CCTK_TerminateNext is declared in cctk_Termination.h not in cctk.h anymore (2001). Also there is not Fortran prototype anymore. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/264> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #213: "cleanup" is implemented twice
by Einstein Toolkit 03 Feb '11

03 Feb '11

#213: "cleanup" is implemented twice ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The functions command_cleanup and CleanupRestarts are very similar. One of them should probably call the other. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/213> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #250: Submitting on numrel07 broken
by Einstein Toolkit 03 Feb '11

03 Feb '11

#250: Submitting on numrel07 broken ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I created and submitted a simulation on numrel07. This aborted with the error message below. Note that "queue" is an optional mdb entry. Executing: ./simfactory/bin/sim create-submit empty- numrel07-2011.01.29-16.57 .03 --parfile=par/empty.par --walltime=1:0:0 --procs=4 --num-threads=4 Error: machine numrel07 is missing a required key: queue DEBUG: Simfactory command: ./simfactory/bin/../lib/sim.py "create-submit" "empty -numrel07-2011.01.29-16.57.03" "--parfile=par/empty.par" "-- walltime=1:0:0" "--p rocs=4" "--num-threads=4" DEBUG: Version exported The Simulation Factory: Manage Cactus simulations Info: defs: /home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/etc/defs.ini Info: defs.local: /home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/etc/defs.local.ini Info: Cactus Directory: /home/eschnett/EinsteinToolkit-hg-vanillaInfo: simenv.COMMAND: create-submit Info: Executing command: create_submitParameter file: /home/eschnett /EinsteinToolkit-hg-vanilla/par/empty.par Info: Configuration name not specified -- using default configuration "sim"Info: Configuration name not specified -- using default configuration "sim" Skeleton Created Job directory: "/home/eschnett/simulations/empty- numrel07-2011.01.29-16.57.03" Executable: "/home/eschnett/EinsteinToolkit-hg-vanilla/exe/cactus_sim" Option list: "/home/eschnett/simulations/empty- numrel07-2011.01.29-16.57.03/SIMF ACTORY/cfg/OptionList" Submit script: "/home/eschnett/simulations/empty- numrel07-2011.01.29-16.57.03/SIMFACTORY/run/SubmitScript" Run script: "/home/eschnett/simulations/empty- numrel07-2011.01.29-16.57.03/SIMFA CTORY/run/RunScript" Parameter file: "/home/eschnett/simulations/empty- numrel07-2011.01.29-16.57.03/S IMFACTORY/par/empty.par"Info: Active Id: -1 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/250> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #220: "sim stop" should be able to stop multiple simulations
by Einstein Toolkit 03 Feb '11

03 Feb '11

#220: "sim stop" should be able to stop multiple simulations -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- If multiple simulations are given as argument to "sim stop", all should be stopped -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/220> 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