Trac February 2013

trac@lists.einsteintoolkit.org

1 participants
177 discussions

[Einstein Toolkit] #1070: EOS_Omni::poly_gamma_ini should default to poly_gamma
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1070: EOS_Omni::poly_gamma_ini should default to poly_gamma -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At the moment, EOS_Omni::poly_gamma and EOS_Omni::poly_gamma_ini are two parameters for the adiabatic exponent, one used only for initial data, the other for evolutions. Both default to 2.0. This means that if someone, unaware of poly_gamma_ini, changes only poly_gamma the result is usually catastrophic (wrong results or c2p failures). I myself didn't notice today and had to debug my way down to find my mistake. I propose to make the default of EOS_Omni::poly_gamma_ini to be whatever EOS_Omni::poly_gamma is. One way to achieve that would be to use some special value for EOS_Omni::poly_gamma_ini which would usually not being used to indicate that behavior and to make that default. However, this being an exponent, at least in theory, all real values are allowed. Another approach would be to introduce a new boolean parameter which would allow users to use an initial value for gamma which is different from the one of the initial data. This would be 'saver', but has the drawback of a new parameter. Nevertheless, I favor the second approach. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1070> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1250: Commit messages for EinsteinExact cannot be sent by email
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1250: Commit messages for EinsteinExact cannot be sent by email ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- I pushed a change to EinsteinExact, and then received an email with an error about this. {{{ Delivered-To: schnetter(a)gmail.com Received: by 10.231.219.129 with SMTP id hu1csp108929ibb; Fri, 8 Feb 2013 05:59:11 -0800 (PST) Received-SPF: pass (google.com: domain of designates 10.58.127.131 as permitted sender) client-ip=10.58.127.131 Authentication-Results: mr.google.com; spf=pass (google.com: domain of designates 10.58.127.131 as permitted sender) smtp.mail=; dkim=pass header.i=(a)google.com X-Received: from mr.google.com ([10.58.127.131]) by 10.58.127.131 with SMTP id ng3mr2795177veb.21.1360331951179 (num_hops = 1); Fri, 08 Feb 2013 05:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:to:x-failed-recipients:subject :message-id:date:content-type; bh=eAu3wQVrCTYeSHXNK+Mirj8Gu6Vb8gznUpvwUkjDfx8=; b=Hsf4XN9B7lyPEwtrbbHu1n4mbBRsOHRXZ/Ss0KRN7N+6GMUuJudI9eswYUAg+WJWXa QWuMgeuy4fGmYwo1wEs0tW14rTQkx2sN+sF+k7CeTnq3U+2H/ysDZX6Is/qvgKeS1jwW 7pxXHOM5rzw/OEvTiByK9wdDryyJTKODc6QzO/hOVIoTiix1Z+YRt6YuRt1X05I6DfU3 ZmFigenS8C8NkMl2PBl1XZSmpJMd772LSJIZ5R4cIpbTXUy1IK9B16Eu/AztG/KNfYvq r9CK/rPjteU4We6Oy1/K9gX8J7aW8/kij0J6VR3yrkJZWdBUeM5ZcVHio0ISU9vm5AbI DGkQ== X-Received: by 10.58.127.131 with SMTP id ng3mr2795177veb.21.1360331951177; Fri, 08 Feb 2013 05:59:11 -0800 (PST) MIME-Version: 1.0 Return-Path: <> Received: by 10.58.127.131 with SMTP id ng3mr2593210veb.21; Fri, 08 Feb 2013 05:59:11 -0800 (PST) From: Mail Delivery Subsystem <mailer-daemon(a)google.com> To: schnetter(a)gmail.com X-Failed-Recipients: einsteinexact-commits(a)googlegroups.com Subject: Delivery Status Notification (Failure) Message-ID: <047d7b604fb6b9fde704d536f63a(a)google.com> Date: Fri, 08 Feb 2013 13:59:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Hello schnetter(a)gmail.com, We're writing to let you know that the group you tried to contact (einsteinexact-commits) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post: * You might have spelled or formatted the group name incorrectly. * The owner of the group may have removed this group. * You may need to join the group before receiving permission to post. * This group may not be open to posting. If you have questions related to this or any other Google group, visit the Help Centre at http://groups.google.com/support/?hl=en-GB. Thanks, Google Groups ----- Original message ----- X-Received: by 10.58.127.131 with SMTP id ng3mr2795174veb.21.1360331951111; Fri, 08 Feb 2013 05:59:11 -0800 (PST) X-Received: by 10.58.127.131 with SMTP id ng3mr2795173veb.21.1360331951101; Fri, 08 Feb 2013 05:59:11 -0800 (PST) Return-Path: <schnetter(a)gmail.com> Received: from smtp1-ext.rs.github.com (smtp1-ext.rs.github.com. [207.97.227.250]) by gmr-mx.google.com with ESMTP id q13si7665238vdh.0.2013.02.08.05.59.11; Fri, 08 Feb 2013 05:59:11 -0800 (PST) Received-SPF: neutral (google.com: 207.97.227.250 is neither permitted nor denied by domain of schnetter(a)gmail.com) client-ip=207.97.227.250; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 207.97.227.250 is neither permitted nor denied by domain of schnetter(a)gmail.com) smtp.mail=schnetter(a)gmail.com Received: from github.com (sh3.rs.github.com [108.171.174.178]) by smtp1-ext.rs.github.com (Postfix) with ESMTP id 3AF69A816B for <einsteinexact-commits(a)googlegroups.com>; Fri, 8 Feb 2013 05:59:10 -0800 (PST) Date: Fri, 08 Feb 2013 05:59:10 -0800 From: Erik Schnetter <schnetter(a)gmail.com> Reply-To: Erik Schnetter <schnetter(a)gmail.com> To: einsteinexact-commits(a)googlegroups.com Message-ID: <511504aed5a7_34b8f5eaec816b8(a)sh3.rs.github.com.mail> Subject: [barrywardell/EinsteinExact] 30ae0d: Improve paramcheck error message Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_511504aeb230_34b8f5eaec814c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Approved: tfq2G6lT+KaWi~M Branch: refs/heads/master Home: https://github.com/barrywardell/EinsteinExact Commit: 30ae0d4036e88f415cda2e4ec8e03e09e0085d15 https://github.com/barrywardell/EinsteinExact/commit/30ae0d4036e88f415cda2e… Author: Erik Schnetter <schnetter(a)gmail.com> Date: 2013-02-04 (Mon, 04 Feb 2013) Changed paths: M m/EinsteinExact.m Log Message: ----------- Improve paramcheck error message }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1250> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1099: CarpetLib::interpolate_from_buffer_zones should by default set to "no"
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1099: CarpetLib::interpolate_from_buffer_zones should by default set to "no" --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2012_11 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- CarpetLib::interpolate_from_buffer_zones should by default set to "no" after it is properly tested and we should think about whether we have a good reason to not remove that paramter then again. Adding the release tag because we don't want to have a change like this affecting two releases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1099> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1249: hwloc requires pkg-config
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1249: hwloc requires pkg-config -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Currently, hwloc generates a fatal error if pkg-config is not available. It is not available on SuperMUC. There is a pre-installed version of hwloc available, and I was able to make it work by modifying configure.sh to comment out references to pkg-config, and re-enable the commented-out lines {{{ HWLOC_INC_DIRS="${HWLOC_DIR}/include" HWLOC_LIB_DIRS="${HWLOC_DIR}/lib" HWLOC_LIBS='hwloc' }}} Would it be correct to try this if pkg-config is not found, or would this lead to hard-to-find errors later on in some situations? The attached patch implements this logic. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1249> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1078: ignore non-evolved points in check_GRHydro_C2P_failed
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1078: ignore non-evolved points in check_GRHydro_C2P_failed -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- The attached patch interfaces GRHydro with Carpet/CarpetEvolutionMask to not abort a run if a con2prim failure happens at points that are not active in the sense that they should not be eg. visualized. CarpetEvolutionMask computes these points by taking the restricted region and modifying it to take buffer zones and ghost zones for prolongation into account. The proposed patch uses Cray pointers (see https://trac.einsteintoolkit.org/ticket/1065) since the Cactus flesh routine to CCTK_VarDataPtr (for Fortran) uses them as well. This requires extra switches for compilers to compile. For gcc the switch is "-fcray- pointer" for intel adding "-safe_cray_ptr" might help efficiency. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1078> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1246: link time errors about builtin_isinf on bethe
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1246: link time errors about builtin_isinf on bethe --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- I get link time errors about missing builtin functions on bethe using the current ET thornlist and a option list with options to disable OMP collapse. This happens with current trunk. If I remember correctly I can circumvent the problem with careful choices for '-Disinf=std::isinf' etc. However this seems like a fudge and dangerous given the amount of work put into getting isnan to work in Cactus recently. Is there a "correct" way to fix this? I attach the make output, options list, thorn list and a list of all thorn revisions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1246> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1248: SimFactory should not silently disable thorns
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1248: SimFactory should not silently disable thorns ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- It is very confusing when you have a thorn in your thornlist, and simfactory silently disables it because it is included in the "disabled- thorns" entry of the machine. SimFactory should at the very least print a message warning the user when the job is submitted that certain thorns requested in the thornlist have been disabled. Printing it when building won't be enough, as the output will likely get lost, but it should also be printed there. It would also be useful to have an option to disable the disabling code, as it has always confused me and wasted my time, and never benefitted me, to my knowledge. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1248> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1243: Allow pseudo-2D domains in CarpetRegrid2
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1243: Allow pseudo-2D domains in CarpetRegrid2 --------------------+------------------------------------------------------- Reporter: knarf | Owner: knarf Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently CarpetRegrid2 contains two asserts that fail for domains that are effectively 2D (but defines as 3D arrays, e.g. (nx,ny,1). The attached patch makes sure these domains don't trigger the assert by checking for ilower==iupper. I also attached a parfile intended as testsuite for this case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1243> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1218: MoL updates
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1218: MoL updates -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The enclosed patches update MoL in three respects: (1) Introduce a function LinearCombination that calculates a linear combination of several grid functions. Use this throughout several (but not yet all) integrators, simplifying the code substantially. This function can also be overloaded to execute on devices if OpenCL or CUDA is used, thus making MoL device aware. (2) Introduce a new integrator "Euler", providing an explicit first-order integrator. This is very handy for debugging. (3) Use cctk_ash instead of cctk_lsh where necessary. Since we use svn, these changed are intermingled in my working directory. I created the patches above manually. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1218> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1134: Adams-Bashforth time integrator
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1134: Adams-Bashforth time integrator -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The attached patch implements Adams-Bashforth time integration in MoL and provides a WaveToy test case. Adams-Bashforth integrators calculate a high-order extrapolation with a single RHS evaluation by combining it with results from previous time steps. This requires multiple time levels for the RHS variables. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1134> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2013