<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 15, 2014 at 4:17 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
  I cannot fix this. There is a cycle in the dependencies if I introduce libraryOptions inside package.py so package.py cannot do the consistency check, but it should so it is totally screwed.<br>
<br>
  Matt could fix it but he'd probably have to fuck up the nice simplicity of the code that is there now :-(!</blockquote><div><br></div><div>We were already using a mechanism to get around this circularity. Comments on the aesthetic import welcome.</div><div><br></div><div>    <a href="https://bitbucket.org/petsc/petsc/branch/knepley/fix-configure-package-check">https://bitbucket.org/petsc/petsc/branch/knepley/fix-configure-package-check</a></div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888"><br>
  Barry<br>
</font></span><div class=""><div class="h5"><br>
> On Dec 15, 2014, at 3:42 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
><br>
>> On Dec 15, 2014, at 3:16 PM, Garth N. Wells <<a href="mailto:gnw20@cam.ac.uk">gnw20@cam.ac.uk</a>> wrote:<br>
>><br>
>> It's possible to configure PETSc with the options<br>
>><br>
>>  --with-64-bit-indices --download-mumps<br>
>><br>
>> and compile and run, but it doesn't look like the MUMPS interface supports 64 bit indices. Should the above combination throw an error at configure time?<br>
><br>
>  Yes, there is commented code in the consistency check, I cannot remember why it was commented.<br>
><br>
> #      if self.double and not self.scalartypes.precision.lower() == 'double':<br>
> #        raise RuntimeError('Cannot use '+<a href="http://self.name" target="_blank">self.name</a>+' withOUT double precision numbers, it is not coded for this capability')<br>
> #      if not self.complex and self.scalartypes.scalartype.lower() == 'complex':<br>
> #        raise RuntimeError('Cannot use '+<a href="http://self.name" target="_blank">self.name</a>+' with complex numbers it is not coded for this capability')<br>
> #      if self.libraryOptions.integerSize == 64 and self.requires32bitint:<br>
> #        raise RuntimeError('Cannot use '+<a href="http://self.name" target="_blank">self.name</a>+' with 64 bit integers, it is not coded for this capability')<br>
><br>
>><br>
>> (On a side note, SuperLU_dist and Umfpack are flaky with 64 bit indices, which seems largely related to calling ParMETIS/METIS).<br>
><br>
>  Hmm, never heard such reports. Are you using the --download-parmetis and metis? You should be. Is it reproducible problem?  We'd like to fix it.<br>
><br>
><br>
>  Barry<br>
><br>
>><br>
>> Garth<br>
>><br>
><br>
<br>
</div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>