[petsc-dev] Source cleanup potpourri

[Matthew Knepley]

On Mon, Feb 11, 2013 at 5:28 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

>
> On Mon, Feb 11, 2013 at 4:06 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>
>> * We have a couple of malloc/free in use:
>> http://krupp.iue.tuwien.ac.at/**petsc-style/malloc-free.txt<http://krupp.iue.tuwien.ac.at/petsc-style/malloc-free.txt>
>> Except for the actual implementation of PetscMalloc() and the like
>> somewhere in src/sys/, is there anything I have to keep in mind when fixing
>> the other uses?
>>
>
> The cases in mesh.c and plex.c are freeing memory allocated by an external
> library.
>

Yep, there is no way around this currently.


> options.c can be processed before the correct malloc implementation has
> been determined (because it can be a command-line option).
>
> str.c stuff can be called before PetscInitialize
>
> hash.h is a third-party library that was brought in and was not fully
> petsc-fied.
>
> yamlimpls.c is freeing memory allocated by an external library
>
> The tfs stuff was contributed and never petsc-fied. I don't think it's
> worth doing maintenance on because it will have to be substantially
> rewritten if someone wants to extend it in a nontrivial way.
>
> That pretty much covers it, so I think PETSc is okay on this front.
>
>
>>
>> * CHKERRQ is missing at a couple of places:
>> http://krupp.iue.tuwien.ac.at/**petsc-style/ierr-chkerr.txt<http://krupp.iue.tuwien.ac.at/petsc-style/ierr-chkerr.txt>
>> I noticed that PetscPrintf() is hardly ever checked for the value of
>> ierr. Is this intentional? If yes, which other functions in PETSc should
>> not be checked for the return value in ierr = ...?
>>
>
> It looks like most of these are accidentally missing. CHKERRABORT can be
> used when the function does not return PetscErrorCode, but the function
> should really be fixed to return PetscErrorCode.
>
>
>>
>> * There is quite some dead code around:
>> http://krupp.iue.tuwien.ac.at/**petsc-style/if0.txt<http://krupp.iue.tuwien.ac.at/petsc-style/if0.txt>
>> Are there any objections (or even LOUD objections) in removing all blocks
>> which are older than ~1 year?
>>
>
> This may need to be done on a case by case basis, but most of it can
> probably go. I wouldn't put any effort into src/dm/impls/{mesh,cartesian}
> because I suspect that code will be deleted en masse within a year.
>

1) Don't remove the dead code in ctetgen.c because I still have to turn on
some of the cooler features (eventually)

2) mesh will be deleted when PyLith and Blaise have fully converted code.
The aim is this summer. I will delete cartesian
    when I have documented the cool Grey code traversals that are buried in
there.

  Matt


>
>> * src/contrib/markadamscolor/**color.c is the only place using assert():
>> http://krupp.iue.tuwien.ac.at/**petsc-style/assert.txt<http://krupp.iue.tuwien.ac.at/petsc-style/assert.txt>
>> Since color.c entered in the previous century and hasn't been notably
>> touched since at least 2001, is there any reason other than software
>> archeology for keeping it?
>>
>
> I don't know what other people think about the contrib directory. It has a
> lot of cobwebs in it, but it can be fun to look at sometimes. The FUN3D
> code in there is now out of date with respect to PETSc and METIS
> interfaces. Somewhere along the line, comp/flow.c became syntactically
> incorrect. (Perhaps reformatting interacted poorly its heavy use of macros.)
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130211/79147c38/attachment.html>