From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1diHLU-0004nt-Vt for guix-patches@gnu.org; Thu, 17 Aug 2017 05:44:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1diHLO-00032r-KB for guix-patches@gnu.org; Thu, 17 Aug 2017 05:44:08 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:33336) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1diHLO-00032k-Fv for guix-patches@gnu.org; Thu, 17 Aug 2017 05:44:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1diHLO-0007KP-0M for guix-patches@gnu.org; Thu, 17 Aug 2017 05:44:02 -0400 Subject: [bug#28045] [PATCH] gnu: Add openfoam Resent-Message-ID: Message-ID: <1502962978.2875.25.camel@tourbillion-technology.com> From: Paul Garlick Date: Thu, 17 Aug 2017 10:42:58 +0100 In-Reply-To: <17DA467A-7864-4EED-9F61-16D634A0B976@centurylink.net> References: <20170811110636.23339-1-pgarlick@tourbillion-technology.com> <20170814214925.2cd96b3f@centurylink.net> <1502905946.2548.31.camel@tourbillion-technology.com> <17DA467A-7864-4EED-9F61-16D634A0B976@centurylink.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Eric Bavier , Marius Bakke Cc: 28045@debbugs.gnu.org Hi Eric, > For metis this might mean a build phase that patches metis.h's > IDXTYPEWIDTH macro appropriately for the target system.  I think this would work, in the sense of allowing OpenFOAM to build.  There has been a recent FreeBSD bug report on this issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219749 The REALTYPEWIDTH would also need to be set to 64-bit for OpenFOAM to avoid a related build problem. However, there could be an argument not to do it this way.  That is, with this approach the choice between 32bit and 64bit integers is made according to the system architecture.  For OpenFOAM, and perhaps other Guix packages too, there is also a consideration of memory usage and speed.   The current default in OpenFOAM is to use 32bit integers, even on 64bit systems.  The reasoning is that the need for indexing beyond the 2^32 limit is restricted to the corner-case of dealing with very large graphs on single processors.  The computations become very time consuming and an attractive alternative in many cases is to parallelise the problem, thereby avoiding the limit. To stick with the OpenFOAM default a 32bit version of scotch/pt-scotch would be needed.  This would mean either reverting commit 26599d6, or introducing a new scotch32 package, the same as the previous definition, guaranteed to use 32bit integers. WDYT? Paul.