From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 16 16:04:49 2017 Received: (at 28045) by debbugs.gnu.org; 16 Aug 2017 20:04:49 +0000 Received: from localhost ([127.0.0.1]:41548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di4Ya-0001ia-TJ for submit@debbugs.gnu.org; Wed, 16 Aug 2017 16:04:49 -0400 Received: from mail.centurylink.net ([205.219.233.9]:54475 helo=smtp.centurylink.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di4YZ-0001iM-4i for 28045@debbugs.gnu.org; Wed, 16 Aug 2017 16:04:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; d=centurylink.net; s=ctl201402; c=relaxed/simple; q=dns/txt; i=@centurylink.net; t=1502913880; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=Hy/oTIGJueE/Rw826JaZg5A1jS4=; b=ZRsg6NVr/2voCnlG38uf9qm0BQwH5Oz19j7MG3xfo655CfJtdqasikBP1N/eCmYu Z31LKuh3Iy8RIer/eSGcdHhfn1E9hyCPzx7t6MazfyaR1W0bi6Y7zVNp/YZUo0JP fTdivSYPo3Pif3PXx9rQ4mTWk+8WRbFxh3PmqLmevUiQBtMI3kLc6DmXxOqC9x3x V8iERpr3YT9549AJdblzIQhWdO8tS4vkplvldbygkk0B8KqzuYc8gNbVu5Qfyq9g dbys2m+uaVCyFvM0YdiC5iSzrmmMEJjC59X9cHTDdVRBqDC3xaa/agy3dlXBoLVi Z4J20NFMcfworujERPdwLQ==; X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=UvUhDK4B c=1 sm=1 tr=0 a=kEoEjvAjDW6duxvNAIOYPw==:117 a=kEoEjvAjDW6duxvNAIOYPw==:17 a=v9CA4rZzAAAA:8 a=3SeSvJxo2j7yxTTwLcsA:9 a=QEXdDO2ut3YA:10 a=TUw19Kr1d9x9EIk-Z98A:9 a=XxpZj4P3yY48yIfh:21 a=_W_S_7VecoQA:10 a=vvO3zLalzpCLnPWG-uKa:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZXJpY2JhdmllckBjZW50dXJ5bGluay5uZXQ= Authentication-Results: smtp02.agate.dfw.synacor.com smtp.user=ericbavier@centurylink.net; auth=pass (LOGIN) Received: from [107.77.164.104] ([107.77.164.104:33564] helo=[10.80.126.121]) by smtp.centurylink.net (envelope-from ) (ecelerity 3.5.1.37854 r(Momo-dev:3.5.1.0)) with ESMTPSA (cipher=AES256-SHA) id 4D/23-15224-655A4995; Wed, 16 Aug 2017 16:04:40 -0400 Date: Wed, 16 Aug 2017 15:04:28 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <1502905946.2548.31.camel@tourbillion-technology.com> References: <20170811110636.23339-1-pgarlick@tourbillion-technology.com> <20170814214925.2cd96b3f@centurylink.net> <1502905946.2548.31.camel@tourbillion-technology.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----AFJ7FZF5SW20V09VZ6FQASFQ7D4RL2" Content-Transfer-Encoding: 7bit Subject: Re: [bug#28045] [PATCH] gnu: Add openfoam To: Paul Garlick , Marius Bakke From: Eric Bavier Message-ID: <17DA467A-7864-4EED-9F61-16D634A0B976@centurylink.net> X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 28045 Cc: 28045@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) ------AFJ7FZF5SW20V09VZ6FQASFQ7D4RL2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Scotch's INTSIZE64 is a bit of a misnomer, as it simply tells scotch to use= the 'long' type rather than 'int'=2E IIRC, Ludovic's rational was that th= is would be 32 bits or 64 bit integers depending on the platform=2E =20 I think this is a reasonable default, but, like you point out, it does mea= n we need to keep thing consistent across packages=2E For metis this might= mean a build phase that patches metis=2Eh's IDXTYPEWIDTH macro appropriate= ly for the target system=2E That should be a separate patch=2E Thanks for working on it, `~Eric On August 16, 2017 12:52:26 PM CDT, Paul Garlick wrote: >Hello Guix, >Thank you Marius and Eric for your reviews and comments=2E >I have been working through the changes and updating the patch=2E >=C2=A0However, in the process of rebasing I have noticed a change in Guix >that impacts on the OpenFOAM definition=2E =C2=A0Specifically, a recent c= ommit >(26599d6) has changed the definition of the scotch package so that it >now uses 64bit integers=2E =C2=A0In a nutshell, this causes a build failu= re in >OpenFOAM=2E >In OpenFOAM, there is a variable to specify the size of the integer >values (32bit or 64bit)=2E =C2=A0This single variable is used by both met= is >and scotch, meaning that they both have to use 32bit integers or both >use 64bit integers=2E =C2=A0At present, Guix offers a 64bit scotch and a = 32bit >metis=2E >A straightforward solution would be to add the extra packages, a 32bit >scotch and/or a 64bit metis=2E =C2=A0For scotch, that would be the same >definition, except for the 'INTSIZE64' line=2E =C2=A0For metis, that woul= d >involve an edit of 'metis=2Eh', setting IDXTYPEWIDTH and REALTYPEWIDTH to >64=2E >Would you prefer this to be the subject of a separate patch, or >included in the OpenFOAM patch? =C2=A0There is also a question about how = to >name the packages; scotch and scotch32, for example, or scotch and >scotch-64int etc=2E >Best regards, >Paul >On Mon, 2017-08-14 at 21:49 -0500, Eric Bavier wrote: >> Hello Paul, >>=20 >> Thank you for the patch! >>=20 >>=20 --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------AFJ7FZF5SW20V09VZ6FQASFQ7D4RL2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Scotch's INTSIZE64 is a bit of a misnomer, as = it simply tells scotch to use the 'long' type rather than 'int&= #39;=2E IIRC, Ludovic's rational was that this would be 32 bits or 64 = bit integers depending on the platform=2E

I think this is a reasonable default, but, like you point out, it does mea= n we need to keep thing consistent across packages=2E For metis this might= mean a build phase that patches metis=2Eh's IDXTYPEWIDTH macro appropr= iately for the target system=2E That should be a separate patch=2E

Thanks for working on it,
`~Eric

On August 16, 2017 12:52:26 PM CD= T, Paul Garlick <pgarlick@tourbillion-technology=2Ecom> wrote:
Hello Guix,

Thank you Marius and Eric for = your reviews and comments=2E

I have been working= through the changes and updating the patch=2E  However, in the proces= s of rebasing I have noticed a change in Guix that impacts on the OpenFOAM = definition=2E  Specifically, a recent commit (26599d6) has changed the= definition of the scotch package so that it now uses 64bit integers=2E &nb= sp;In a nutshell, this causes a build failure in OpenFOAM=2E

In OpenFOAM, there is a variable to specify the size of the in= teger values (32bit or 64bit)=2E  This single variable is used by both= metis and scotch, meaning that they both have to use 32bit integers or bot= h use 64bit integers=2E  At present, Guix offers a 64bit scotch and a = 32bit metis=2E

A straightforward solution would = be to add the extra packages, a 32bit scotch and/or a 64bit metis=2E  = For scotch, that would be the same definition, except for the 'INTSIZE64' l= ine=2E  For metis, that would involve an edit of 'metis=2Eh', setting = IDXTYPEWIDTH and REALTYPEWIDTH to 64=2E

Would yo= u prefer this to be the subject of a separate patch, or included in the Ope= nFOAM patch?  There is also a question about how to name the packages;= scotch and scotch32, for example, or scotch and scotch-64int etc=2E
<= div>
Best regards,

Paul

On Mon, 2017-08-14 at 21:49 -0500, Eric Bavier wrote:
Hello Paul,

Thank you for the patch!



--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------AFJ7FZF5SW20V09VZ6FQASFQ7D4RL2--