Present were: Frank, Roland, Bruno, Ian, Erik
ET release: * all (trunk,master) branches open development again * currently large number of tickets for review (13), please take time to review one [1]
MHD status: * Bondi still fails, Bruno has fixes coded up but not yet tested * rotating collapse: various tests over weekend, none succeeded, higher-order interpolation not yet coded or tried
Next release: * milestones are currently used to tag what (ticket, enhancement) we want to include in the next release, not necessary how important (severe) an issue is * suggested major release goal: scheduler improvements * query on cactususers for suggestions for next release goal
Misc: * Roland will likely host the next call
Yours, Roland
[1] https://trac.einsteintoolkit.org/query?status=%21closed&milestone=ET_201...
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 will setup a cron job updating this graph every night and announce once that is setup and working.
In principle this should be an easy addition to any already present automated build (just build with -Wall, capture the build logs and run two scripts to generate that plot). However, the current script is likely to get confused if the build is done in parallel and thus the log is all mixed up, so I build in serial for this for now. I opened a ticket (https://trac.einsteintoolkit.org/ticket/1180) to collect ideas how to deal with that.
Frank
The following links are _not_ persistent.
[1] http://www.cct.lsu.edu/~knarf/ET_stats/warnings.png [2] http://www.cct.lsu.edu/~knarf/ET_stats/build.log ( 39MB )
On Thu, Nov 15, 2012 at 11:49 PM, Frank Loeffler knarf@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.
Many unused variables come from Kranc-generated code.
Many of the warnings about shadowed variables come from thorn Vectors. When I originally designed Vectors, it was not possible to use inline functions due to limitations in some compilers. With macros, of course, one either has to use different variable names in each macro, or variables are going to shadow each other.
-erik
On Thu, Nov 15, 2012 at 11:49 PM, Frank Loeffler knarf@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.
We should define what warning options we want to enable for which compilers (and compiler versions). For example, -Wall goes without saying, but there are other options that may be less useful because the flag code that is almost always correct.
-erik
On Thu, Nov 15, 2012 at 11:49 PM, Frank Loeffler knarf@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.
-erik
On 21 Nov 2012, at 17:52, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Thu, Nov 15, 2012 at 11:49 PM, Frank Loeffler knarf@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.
On Wed, Nov 21, 2012 at 12:00 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 21 Nov 2012, at 17:52, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Thu, Nov 15, 2012 at 11:49 PM, Frank Loeffler knarf@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
Hello all,
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.
LSUThorns::Refluxing's capture variables for fluxes of vector variables are of that type (eg sconflux_register_fine). I don't think that they have symmetries applied to them though so Erik's statement is correct.
Yours, Roland
On Wed, Nov 21, 2012 at 12:14 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
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.
LSUThorns::Refluxing's capture variables for fluxes of vector variables are of that type (eg sconflux_register_fine). I don't think that they have symmetries applied to them though so Erik's statement is correct.
Oops. I didn't think of these.
Since fluxes are staggered, and since RotatingSymmetry90 doesn't know about this, there would be a host of other problems if they had boundary conditions applied.
-erik
Hi,
On Thu, Nov 15, 2012 at 10:49:40PM -0600, Frank Loeffler wrote:
I will setup a cron job updating this graph every night and announce once that is setup and working.
The not yet final location is http://www.cct.lsu.edu/~knarf/ET_stats/warnings.png and http://www.cct.lsu.edu/~knarf/ET_stats/build.log - generated every night from the current ET trunk.
Frank
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Roland Haas