Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #471: GetComponents: Allow !ANON_USER and !ANON_PASS not to be specified in a cvs checkout.
by Einstein Toolkit 31 Aug '11

31 Aug '11

#471: GetComponents: Allow !ANON_USER and !ANON_PASS not to be specified in a cvs checkout. ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I would like to checkout cvs modules from a repository where ssh keys and ssh-agent are used to allow for a passwordless checkout. At the moment GetComponent doesn't seem to handle well this case. For example, once my keys are hold by ssh-agent the following command allows me to checkout cvs_module located at cvs_repo_path on cvsrepo repository: cvs -d :ext:cvsrepo:cvs_repo_path co path_to_module/cvs_module However if I set on the CRL file the following directives: !TARGET = $ARR !TYPE = cvs !URL = :ext:cvsrepo:cvs_repo_path !REPO_PATH = path_to_module/$1 !CHECKOUT = cvs_module I got the following error: Checking out module: cvs_module from repository: :@:ext:cvsrepo:cvs_repo_path into: Cactus/arrangements Executing: cvs -z9 -q -d :@:ext:cvsrepo:cvs_repo_path checkout cvs_module In: Cactus/arrangements cvs checkout: Unknown method (`@') in CVSROOT. cvs [checkout aborted]: Bad CVSROOT: `:@:ext:cvsrepo:cvs_repo_path'. This happens because GetComponents expects the directives !ANON_USER and !ANON_PASS to be specified in a anonymous checkout (as I usually set when I use ssh keys to authenticate my access to a particular repository). However in doing so it prevents a passwordless checkout. The attached patch fix this problem, but maybe the best solution would be to allow the user to specify a promptless !AUTH_URL directive so that "$user:$pass\@" is not included in the repository specification. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/471> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #538: Enable CSE in McLachlan
by Einstein Toolkit 28 Aug '11

28 Aug '11

#538: Enable CSE in McLachlan -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Kranc supports CSE, which has the potential to reduce code size and improve performance. We should enable it in McLachlan. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/538> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #541: Use ssh control connections to speed up remote access
by Einstein Toolkit 28 Aug '11

28 Aug '11

#541: Use ssh control connections to speed up remote access -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Ian and Barry reported using this; it would be great if this could be automated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/541> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #436: NaNs in the AMR boundary closest to Pi symmetry boundary around 10M of evolution
by Einstein Toolkit 27 Aug '11

27 Aug '11

#436: NaNs in the AMR boundary closest to Pi symmetry boundary around 10M of evolution -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The parameter file attached runs smoothly with the ET curie release version. However when I use the current ET development version, NaNs show up in the AMR boundary closest to Pi symmetry boundary around 10M of evolution. This happens for the second finest grid level. I am repeating the experiment without Pi symmetry and I will report on its result shortly. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/436> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #342: Add CCTK_POINTER_SIZE make variable
by Einstein Toolkit 27 Aug '11

27 Aug '11

#342: Add CCTK_POINTER_SIZE make variable -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: flesh | -------------------------+-------------------------------------------------- It is sometimes necessary to know in a thorn's configuration script whether 32 bit or 64 bit code is to be generated. See the discussion in ticket #339. The attached patch adds a CCTK_POINTER_SIZE make variable to make.config.defn which is accessible as a shell variable to configuration scripts. This will be 4 when compiling for 32 bit, and 8 when compiling for 64 bit. I am not very expert in autoconf, so the patch might have to be modified. It seems to work, however. I have not included the generated configure script - this should be generated by the person who commits the final patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/342> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #489: Hydro_InitExcision test cases failing - shift_state = 0 no longer supported
by Einstein Toolkit 27 Aug '11

27 Aug '11

#489: Hydro_InitExcision test cases failing - shift_state = 0 no longer supported -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Hydro_InitExcision | -----------------------------------+---------------------------------------- All of the Hydro_InitExcision test cases are failing. The error seems to be WARNING level 0 in thorn GRHydro processor 0 host sl-18.damiana.admin (line 128 of GRHydro_Boundaries.F90): -> shift_state = 0 (no shift storage) no longer supported! [1mWARNING level 0 in thorn GRHydro processor 0 host sl-18.damiana.admin (line 128 of GRHydro_Boundaries.F90): ->[0m shift_state = 0 (no shift storage) no longer supported! They started failing on 04-08-2011 when this check was added in GRHydro. See attached diff for what changed in the Cactus tree between the test passing and failing. I don't know the code, but would it make sense to change ADMBase::initial_shift = "none" to ADMBase::initial_shift = "zero" in the test parameter files? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/489> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #536: Don't overload machines while building
by Einstein Toolkit 26 Aug '11

26 Aug '11

#536: Don't overload machines while building -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: optional | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Certain machines are easily overloaded by building Cactus; building multiple configurations at the same time is not possible there. For example, LONI does not have sufficient compiler licences, or Orca (Sharcnet) does not allow sufficiently many user processes. On LONI, things will be very slow (also for other users), on Orca building will fail with strange error messages. I suggest a mechanism that automatically serialises building Cactus configuration on certain sets of machines. Ideally, one would extend the "make -j" mechanism for this; practically, an implementation via locks may be simpler. Note that this has to work for sets of machines, not just single machines. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/536> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Re: [ET Trac] [Einstein Toolkit] #52: Ensure consistency between configurations on different systems
by Einstein Toolkit 26 Aug '11

26 Aug '11

1 0

[Einstein Toolkit] #491: RotatingSymmetry180 and RotatingSymmetry90 test cases failing
by Einstein Toolkit 26 Aug '11

26 Aug '11

#491: RotatingSymmetry180 and RotatingSymmetry90 test cases failing -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The thorns RotatingSymmetry180 and RotatingSymmetry90 started failing their tests on 03-Aug-2011. This is probably the same root cause as #490: McLachlan test case failing due to ADMBase variable differences There are substantial differences in the extrinsic curvature, dtlapse, lapse and ml_admconstraints well above roundoff. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/491> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Re: [ET Trac] [Einstein Toolkit] #52: Ensure consistency between configurations on different systems
by Einstein Toolkit 26 Aug '11

26 Aug '11

#52: Ensure consistency between configurations on different systems --------------------------+------------------------------------------------- Reporter: anonymous | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Comment (by hinder): At the moment I have configurations for both Damiana and Datura in the same source tree, but--as suggested I think by Erik--this would be better handled by having different source tree locations for the different machines (they share a head node and home filesystem). Most of the time I just use the default configuration name of "sim". I would like this to use the default thornlist I have configured in defs.local.ini, which used to work but I believe is now broken (I should create a ticket for this). However, I also use other configurations. For example I might have a small configuration for testing simfactory, another for testing Kranc examples, maybe one for Carpet-Git and another for Carpet-HG (I put the different Carpets in different arrangements in the same source tree). So yes, I have multiple configurations. I think a mapping between thornlists and configurations makes sense, in the same way as I virtually always have a mapping between parameter files and simulations. The only problem with this is that thornlist names tend to be long and the configuration name would have to be typed for every simfactory command. This could be solved by supporting [http://www .debian-administration.org/articles/316 bash-completion] in simfactory so that you could tab-complete on the configuration name. One could also use short names for thornlists instead of long names. So, I support the original suggestion and think it is a good idea. It would be useful in the case where I have an old configuration and can't remember what thornlist I used for it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/52#comment:3> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011