Trac March 2012

trac@lists.einsteintoolkit.org

1 participants
156 discussions

[Einstein Toolkit] #770: franklin and kraken hostname identification conflicts
by Einstein Toolkit 05 May '12

05 May '12

#770: franklin and kraken hostname identification conflicts ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The alias patterns used in franklin.ini {{{ ^nid[0-9][0-9][0-9][0-9][0-9](\.nersc\.gov)?$ }}} matches one of the alias of a kraken head node. In particular I get aliases (on kraken-gsi4): {{{ ['c1-1c1s5n0', 'login16', 'logingsi4', 'krakenpf16', 'kraken-gsi4'] }}} which matches the nid pattern. I am not sure if franklin and kraken actually share head nodes or not. If not then a more restrictive alias pattern for franklin might help, though I have no access to it so cannot test it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/770> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #686: Handle requirements recursively
by Einstein Toolkit 02 May '12

02 May '12

#686: Handle requirements recursively ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- [This patch includes CreateConfigurationBindings-cleanup.patch (#685): once CreateConfigurationBindings-cleanup.patch has been applied, the diffs in this patch will be much reduced in size.] Handle requirements recursively: If A requires B, and B requires C, then A also requires C. This is necessary e.g. for include directories: If A includes a file from B, which in turn includes a file from C, then C's include directory must be in the search path of A. Complete implementation of INCLUDE directives when parsing configuration.ccl scripts. Add more stringent checking of capability names: Only identifiers are allowed. This prevents the capability ":" from appearing when syntax errors in configuration.ccl files are not detected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/686> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #713: Implement "Conformal Covariant Z4" formulation in McLachlan
by Einstein Toolkit 02 May '12

02 May '12

#713: Implement "Conformal Covariant Z4" formulation in McLachlan -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The [http://arxiv.org/abs/1106.2254 conformal covariant Z4] formulation is a variant of the Z4 system which can be implemented as a modification to existing BSSN codes through the addition of some terms and a single evolved grid function. Dana Alic implemented and tested this in McLachlan. I have created a "CCZ4" branch and committed her work, then merged some recent changes which were committed to the master branch since the version she based her code off of. It would be nice to merge this branch back into master, but I am unsure how to proceed. Two options are: 1. Create a separate Kranc script for the CCZ4 system. This has the advantage of keeping the existing code tidier and easier to read. 2. Keep a single Kranc script and add a parameter to select which formulation to use. This may make it easier to maintain both versions as there is a very large overlap between the two. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/713> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #664: track should have a "reviewed" state for tickets whose attached patch has been reviewed
by Einstein Toolkit 30 Apr '12

30 Apr '12

#664: track should have a "reviewed" state for tickets whose attached patch has been reviewed ----------------------------------+----------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- A typical tickets live-cycle would be: * open * possibly accept or reassign * review * reviewed * closed with possible several iterations through the review and reviewed states. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/664> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #681: LSUThorns/Vectors: Update Kranc-specific code
by Einstein Toolkit 26 Apr '12

26 Apr '12

#681: LSUThorns/Vectors: Update Kranc-specific code -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/681> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #752: GetComponents hangs when "svn info" reports a certificate warning
by Einstein Toolkit 25 Apr '12

25 Apr '12

#752: GetComponents hangs when "svn info" reports a certificate warning ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ This is similar to, but not the same as, #135. The problem is that GetComponents runs "svn info" on a repository with https where SVN thinks the certificate is not valid: {{{ MacBook-2:manifest (master) $ svn info --username hinder https://svn.cactuscode.org/arrangements/CactusNumerical/MoL/device Error validating server certificate for 'https://svn.cactuscode.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.cactuscode.org - Valid: from Thu, 05 Jan 2012 21:31:52 GMT until Fri, 04 Jan 2013 21:31:52 GMT - Issuer: lsu, edu - Fingerprint: d1:ea:8a:9a:a8:7d:a5:15:7a:56:22:27:99:30:96:d7:e4:38:0e:53 (R)eject, accept (t)emporarily or accept (p)ermanently? }}} This causes GetComponents to hang permanently with no indication of what is wrong. The solution to #135 was to add --non-interactive to the "svn update" command, and "svn info" also supports such an option. Should it be added here as well? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/752> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #339: ExternalLibraries/OpenSSL does not compile in 64-bit mode on Mac OS
by Einstein Toolkit 23 Apr '12

23 Apr '12

#339: ExternalLibraries/OpenSSL does not compile in 64-bit mode on Mac OS ---------------------------------------+------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: ExternalLibraries/OpenSSL | ---------------------------------------+------------------------------------ Compiling OpenSSL using ExternalLibraries leads to the following warning, followed by a build failure: + cd openssl-1.0.0d + ./config --prefix=/Users/ian/Cactus/et/configs/fink/scratch/external/OpenSSL Operating system: i686-apple-darwinDarwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 WARNING! If you wish to build 64-bit library, then you have to invoke './Configure darwin64-x86_64-cc' *manually*. You have about 5 seconds to press Ctrl-C to abort. Configuring for darwin-i386-cc I don't know how to detect that the compiler is building in 64-bit mode in order to add the corresponding flag to the Configure line. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/339> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #685: Cleanup in script CreateConfigurationBindings.pl
by Einstein Toolkit 18 Apr '12

18 Apr '12

#685: Cleanup in script CreateConfigurationBindings.pl -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Some cleanup: Use my, use better variable names, re-indent. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/685> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #430: Convert all parameter files, examples, and test cases to EOS_Omni
by Einstein Toolkit 17 Apr '12

17 Apr '12

#430: Convert all parameter files, examples, and test cases to EOS_Omni -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Now that EOS_Omni is standard, we should convert all parameter files. At the moment, these parameter files still reference EOS_Base: EinsteinInitialData/TOVSolver/test/test_one_boost_max/test_one_boost_max.par EinsteinInitialData/TOVSolver/test/test_one_static_max/test_one_static_max.par EinsteinInitialData/TOVSolver/test/test_tov_carpet/test_tov_carpet.par EinsteinInitialData/TOVSolver/test/test_two_av/test_two_av.par EinsteinInitialData/TOVSolver/test/test_two_max/test_two_max.par LSUDevelopment/Refluxing/par/GRHydro_Carpet_Shocktube_base_works_with_gitCarpet.par The Refluxing parameter file is for reference only and should be remove now that hg Carpet is the default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/430> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #493: All checkpoint files used in test suite need to be regenerated to work with development Carpet
by Einstein Toolkit 17 Apr '12

17 Apr '12

#493: All checkpoint files used in test suite need to be regenerated to work with development Carpet --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The current stable and development (git and mercurial) versions of Carpet use incompatible checkpoint file formats. Neither can read the checkpoints generated by the other (http://lists.einsteintoolkit.org/pipermail/users/2011-August/001299.html). The tests checkpointML, recoverML, CarpetWaveToyNewRecover_test_1proc and CarpetWaveToyRecover_test_1proc need to have their checkpoint files regenerated. At this point, it is likely that these tests will start to fail for the stable version of Carpet, but making the stable version read these files would be more effort than it is worth. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/493> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2012