[petsc-dev] broken stuff in next please fix

[Barry Smith]

On Jan 5, 2014, at 1:09 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
> 
>>   I have switched back to using the
>>   mpich-master-v3.0.4-106-g3adb59c.tar.gz I messed up and put that
>>   change into a commit when I shouldn’t have. (I still miss the nice
>>   bk gui that showed cleanly each change you were committing).
> 
> I never used the bk gui, but what is lacking in "git gui" or sourcetree?
> 
>>   But it is extremely worrisome that we need to use PARTICULAR
>>   versions of MPI implementations to get clean compilers?!?!?!
>> 
>>   1) Isn’t this fundamentally wrong? 
> 
> Like all dependencies, MPI implementations can have bugs.  This was a
> bug and was fixed before it spent much time in the wild.  

    It appears that this bug appeared in a release and hence could affect many users.  I think configure should detect it and do either A) or B) otherwise it looks to all users like a bug in PETSc, when it is not.  Yes we cannot catalog all bugs but ones that we know about and that make PETSc look bad should be handled.
 

   Barry


> The memory bug
> is more subtle and I have no idea why mpich-3.0.5 has not been released.
> 
>>   1.5) Do we want to be in the business of saying, “if you use
>>   compiler XX version YY then you need to use MPICH implementation
>>   version ZZ, otherwise it won’t work?
> 
> This is just a warning, but some MPI implementations have functions that
> crash at runtime.  Others have space leaks (e.g., V1R2M0 on BG/Q).
> 
>>   2) Shouldn’t we be portable to all the various MPI implementations that are released at various times? 
>> 
>>   3) Do we need a configure test to properly handle the “broken” MPI implementations? 
> 
> Lots of compilers have bugs too, including wrong code.  I don't think
> it's maintainable to catalog all the bugs in all dependencies on all
> architectures.  If something is buggy on a popular system, such that it
> creates complaints, we can work around it.  Note that some packages like
> ParMETIS have major open bugs that people hit all the time, and we
> maintain patches that upstream inexplicably does not apply.
> 
> In the case of MPI type tags, the user encounters the same warnings if
> they use MPI_2INT.
> 
> 
> Public shaming for known bugs that intentionally cannot be detected at
> configure time is one marginally-effective recourse.