[Users] meeting minutes

[Erik Schnetter]

On Wed, Nov 21, 2012 at 12:00 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> On 21 Nov 2012, at 17:52, Erik Schnetter <schnetter at cct.lsu.edu> wrote:
>
>> On Thu, Nov 15, 2012 at 11:49 PM, Frank Loeffler <knarf at cct.lsu.edu> wrote:
>>> On Mon, Nov 12, 2012 at 08:56:10AM -0800, Roland Haas wrote:
>>>> Next release:
>>>> * query on cactususers for suggestions for next release goal
>>>
>>> We also talked about trying to look into the number of compiler warnings
>>> that are generated. I produced a graph showing the status as of the last
>>> release [1], parsed from the output of a build [2]. Most of the warnings
>>> are produced from auto-generated code, for shadowed and/or unused
>>> variables; and Ian Hinder has some ideas about how to fix this. Others
>>> will have to be looked into by hand.
>>
>> I have begun to look into the reported warnings. Most are harmless and
>> can be corrected very easily. Some point to cases where an error check
>> in the code is missing. Other are difficult to avoid, e.g. when
>> "const" or "restrict" is involved.
>>
>> And in one case I found an actual error in RotatingSymmetry90. Tensor
>> indices where calculated in the wrong way. This concerns "dd" tensors,
>> i.e. 3x3 tensors without symmetry. I believe we don't use these, so
>> the error went undetected.
>
> I have eliminated a few thousand warnings (those from Kranc-generated code) as well as in a few other places.  As Erik said, these are usually about adding an error check.  We now have about 1000 warnings remaining.  Of these, 340 come from one particular repeated macro call in LocalReduce.  I couldn't see a quick fix for this because the code is a little bit involved (as usual with macro code).  I expect that many of these come from repetitive code which can be fixed in a batch rather than having to investigate and solve 1000 different problems.

I may have mentioned before that LocalReduce has many problems. The
highly repetitive nature of the code is the most obvious; it also
contains errors in the definitions of the reduction operators, at
least for complex numbers. I suggest to not try and fix it, as this
would require analysing the thorn to ensure that the warnings are
actually harmless. (I obviously object to simply "papering over"
warnings to make them go away.) Using C++ and templates would lead to
a much smaller, simpler thorn.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/