Trac

trac@lists.einsteintoolkit.org

8708 discussions

[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

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

25 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 eschnett): One of Simfactory's goals is to remove the difference between different machines. Ideally, one would just "submit" a simulation, and some semi- automated mechanism would figure out where to submit (or would submit multiple times and keep only the first job that then starts), or would allow easily to restart on a different system, allows monitoring all current simulations independent of where they are running, etc. I have two thorn lists (development and production) in two different source trees, and use the same thorn lists on all systems. If a thorn doesn't work on a particular system this is noted in the MDB. I almost never specify a configuration name manually. If the default changed from "sim" to the thorn list name, I would not be bothered much. In a way, this ticket is already implemented. Simfactory distributes e.g. the manifest directory, and one can set a default thorn list in defs.local.ini. Are there people who regularly build multiple configurations in the same source tree? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/52#comment:2> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

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

25 Aug '11

1 0

[Einstein Toolkit] #516: Enable Vectorisation in McLachlan
by Einstein Toolkit 25 Aug '11

25 Aug '11

#516: Enable Vectorisation in McLachlan -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Kranc generated thorns now have support for optimisation through vectorisation. They just need the option UseVectors -> True to be set when creating the thorn. The attached patches enable this for the BSSN thorns in McLachlan. I have tested that this gives a significant performance increase (close to 2x in the right-hand-sides in the cases I tried) and also that it agrees to within what would be expected given roundoff differences with the results of a BBH simulation with vectorisation disabled. Additionally, the testsuites still pass with this patch applied. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/516> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #490: McLachlan test case failing due to ADMBase variable differences
by Einstein Toolkit 25 Aug '11

25 Aug '11

#490: McLachlan test case failing due to ADMBase variable differences -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The McLachlan test ML_BSSN_sgw3d has been failing since 03-Aug-2011. The only tested variable which is showing differences is kxx, but the differences appear to be significantly larger than roundoff: kxx.x.asc: substantial differences significant differences on 16 (out of 36) lines maximum absolute difference in column 13 is 0.000822901437894541 maximum relative difference in column 13 is 0.0560528644051835 (insignificant differences on 16 lines) This coincides with the following commit: commit 3ba8a55ae2578cb6dc06f0ec8b81f86b3a2654ac Author: Erik Schnetter <schnetter(a)cct.lsu.edu> Date: Tue Aug 2 20:37:19 2011 -0400 Correct schedule, in particular for checkpoint/recovery Do not mark ADMBase variables for non-checkpointing if they have multiple timelevels. (Variables with multiple timelevels must always be checkpointed, because the past timelevels cannot be regenerated after recovery.) Finally remove all perl post-processing of the auto-generated code; instead, use proper Kranc mechanisms. Schedule the ADM constraints and ADM quantities after MoL_PostStep, since this is where the ADMBase variables are set. Schedule enforcing the BSSN constraints in the new schedule group MoL_PostStepModify, since they should not be enforced after recovery. (This would lead to inconsistencies at floating-point round-off level.) Regenerate all thorns. and the other commits made to Cactus at the same time as explained in this email: http://cactuscode.org/pipermail/users/2011-July/002872.html Attached is a diff which shows what changed between the test passing and failing. Since this test does not deal with checkpointing or recovery, I don't understand why kxx should change so drastically. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/490> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #438: Allow a configuration.ccl for the flesh
by Einstein Toolkit 25 Aug '11

25 Aug '11

#438: Allow a configuration.ccl for the flesh ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- The mechanism in Cactus that handles configuration.ccl files currently cannot handle a configuration.ccl for the flesh. The enclosed patch corrects this. This is a prerequisite for moving the MPI configuration code out of the flesh and into a thorn (as we already did for all other external libraries). The flesh will need to know whether MPI is used or not, since MPI needs to be initialized before the parameter file is read. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/438> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac