From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1di4Yr-0000zW-NL for guix-patches@gnu.org; Wed, 16 Aug 2017 16:05:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1di4Yo-0002qb-II for guix-patches@gnu.org; Wed, 16 Aug 2017 16:05:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:32868) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1di4Yo-0002qF-D7 for guix-patches@gnu.org; Wed, 16 Aug 2017 16:05:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1di4Yn-0001j4-Uv for guix-patches@gnu.org; Wed, 16 Aug 2017 16:05:01 -0400 Subject: [bug#28045] [PATCH] gnu: Add openfoam Resent-Message-ID: Date: Wed, 16 Aug 2017 15:04:28 -0500 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 From: Eric Bavier Message-ID: <17DA467A-7864-4EED-9F61-16D634A0B976@centurylink.net> 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: Paul Garlick , Marius Bakke Cc: 28045@debbugs.gnu.org ------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--