Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #671: ML_ADMConstraints is incorrect
by Einstein Toolkit 20 Nov '11

20 Nov '11

#671: ML_ADMConstraints is incorrect -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: ML_ADMConstraints | -----------------------------------+---------------------------------------- ML_ADMConstraints does not compute the constraints correctly. There are errors in the computation of the Ricci tensor. The attached patch corrects these errors. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/671> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #672: McLachlan code should be regenerated
by Einstein Toolkit 20 Nov '11

20 Nov '11

#672: McLachlan code should be regenerated -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The code generated by the current version of Kranc no longer matches that stored in the McLachlan repository. The attached patch brings McLachlan up to date. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/672> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #673: Broken links on carpetcode.org
by Einstein Toolkit 19 Nov '11

19 Nov '11

#673: Broken links on carpetcode.org --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: web | --------------------+------------------------------------------------------- carpetcode.org has several broken links. PDF of the link check attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/673> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #670: commit 166d77a440a5 and b5f8b4ff16fb does not compile with gfortran
by Einstein Toolkit 16 Nov '11

16 Nov '11

#670: commit 166d77a440a5 and b5f8b4ff16fb does not compile with gfortran --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- I get the following error messages (the second commit changes make.code.defn to activate code from the first commit): {{{ In file /home/rhaas/ET/configs/et/build/Carpet/LoadBalanceReal/carpet_region.f90:59 type(superregion2), pointer, intent(out) :: sregion 1 Error: POINTER attribute conflicts with INTENT attribute at (1) }}} this happens with gfortran 4.2 on a red hat 5.7 system (eg. the cct machines or my workstation at Caltech or (former workstation at) GT). I attach the full make output (with many more errors). Looking at the fortran code it states that: {{{ ! Note that using intent on pointer arguments requires fortran 2003. ! It is not allowed in fortran 90 or 95. }}} I tried setting std=f2003 in gfortran (see make.log) but apparently this is not sufficient for gfortran 4.1.2 I am not which other fortran compilers are affected. If we keep this then we will have to make very clear all user realise that Carpet requires Fortran 2003 and a fairly new gfortran compiler (or intel) not just Fortran 90. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/670> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #495: MPI error from Carpet with QuasiLocalMeasures: "MPI_SUM is not defined for non-intrinsic datatypes"
by Einstein Toolkit 14 Nov '11

14 Nov '11

#495: MPI error from Carpet with QuasiLocalMeasures: "MPI_SUM is not defined for non-intrinsic datatypes" --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- In the development (Mercurial) version of Carpet, but not the stable (Git) version, QuasiLocalMeasures fails with the following error message: ... INFO (QuasiLocalMeasures): Landau-Lifshitz angular momentum x: 0.00000 INFO (QuasiLocalMeasures): Landau-Lifshitz angular momentum y: 0.00000 INFO (QuasiLocalMeasures): Landau-Lifshitz angular momentum z: 0.00000 [sl-18:26396] *** An error occurred in MPI_Reduce: the reduction operation MPI_SUM is not defined for non-intrinsic datatypes [sl-18:26396] *** on communicator MPI COMMUNICATOR 3 SPLIT FROM 0 [sl-18:26396] *** MPI_ERR_OP: invalid reduce operation [sl-18:26396] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort) This affects the QuasiLocalMeasures test suite, but was also reported and discussed on the ET mailing list: http://lists.einsteintoolkit.org/pipermail/users/2011-May/001107.html Additional debugging was suggested to try to locate the reason for the error. (Reporting against Carpet even though it might be a problem in QuasiLocalMeasures because it works in the stable Carpet and this will be a possible blocker for promoting the development Carpet to stable). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/495> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
by Einstein Toolkit 13 Nov '11

13 Nov '11

#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead? ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: EOS_Omni HDF5 | ---------------------------+------------------------------------------------ At the moment EOS_Omni requires the HDF5 library to read the nuclear EOS values from a table. Since not all distros have fortran support for the HDF5 library as a default, I propose to change this requirement and provide a fall back in case this support is not present. Perhaps not using the nuclear EOS, or reading from an ASCII file instead. This could be just a temporary solution until the HDF5 library build script becomes more robust. Opinions? Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/145> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #662: init_3_timelevels seems to fail on Maxwell
by Einstein Toolkit 11 Nov '11

11 Nov '11

#662: init_3_timelevels seems to fail on Maxwell ---------------------------------+------------------------------------------ Reporter: yosef@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: init_3_timelevels | ---------------------------------+------------------------------------------ If I use the carpet::init_3_timelevels=yes I get the following error WARNING level 0 in thorn CarpetLib processor 0 host quasar.ccrg.rit.edu (line 385 of /home/yosef/ET/Maxwell/Cactus/configs/lazev/build/CarpetLib/gdata.cc): -> Internal error: extrapolation in time. variable=ADMBASE::alp time=1280 times=[2560,4955,2395] WARNING level 0 in thorn CarpetLib processor 0 host quasar.ccrg.rit.edu (line 385 of /home/yosef/ET/Maxwell/Cactus/configs/lazev/build/CarpetLib/gdata.cc): -> Internal error: extrapolation in time. variable=ADMBASE::alp time=1280 times=[2560,4955,2395] This error message did not occur when I ran with the previous -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/662> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #470: Check is wrong inside prolongate_3d_o1_rf2.cc
by Einstein Toolkit 10 Nov '11

10 Nov '11

#470: Check is wrong inside prolongate_3d_o1_rf2.cc ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | ---------------------+------------------------------------------------------ The problem materialized when creating wave equation tutorials for the Teragrid conference. I was unable to run an FMR application in parallel. The check comprises lines 76-80 of the file: if (not regbbox.expand(offsetlo, offsethi).is_contained_in(srcbbox) or not regbbox .is_contained_in(dstbbox)) { CCTK_WARN (0, "Internal error: region extent is not contained in array extent"); } -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/470> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #627: add coordinates of minimum and maximum in reduction operators
by Einstein Toolkit 10 Nov '11

10 Nov '11

#627: add coordinates of minimum and maximum in reduction operators ------------------------------------------------+--------------------------- Reporter: bruno.giacomazzo@… | Type: enhancement Status: new | Priority: major Milestone: | Component: Cactus Version: | Keywords: ------------------------------------------------+--------------------------- In several cases it would be useful for some quantities to know not only their maximum (minimum), but also the (x,y,z) coordinates of the position of their maximum (minimum). Is it possible to modify the reduction operators so that the maximum/minimum can return also the position on the grid of the maximum/minimum of a quantity? According to the Cactus manuals this does not seem possible now. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/627> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #365: ADMBase: evolving with evolution_method="static" does not apply boundary conditions
by Einstein Toolkit 10 Nov '11

10 Nov '11

#365: ADMBase: evolving with evolution_method="static" does not apply boundary conditions ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- When one uses the evolution method ADMBASE::evolution_method = "static" (which is very tempting e.g. for Cowling), then no boundary conditions are applied. This means that the ADMBase variables remain unset on the boundaries after regridding, leading to all sorts of (rather unexpected) problems. The easy solution is to use thorn Exact instead, which applies an exact solution at each time step, including on the boundary. I suggest to remove the ADMBase functionality to provide a "static" evolution method, since this evolution method does not know which boundary condition to apply, and hence is bound to fail in non-trivial situations. Alternatively, ADMBase needs to synchronise in postregrid (and probably a few other bins as well). ADMBase should then also offer to apply an outer boundary condition, in this case probably a Minkowski Dirichlet boundary condition or a von Neumann condition. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/365> 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