EPx Project

[Stuart Mentzer]

Greetings EPx developers,

My company, Objexx Engineering, will be working with the EPx source in some detail. I wanted to first say Hi and to let the community know what we are doing and how to best collaborate with the rest of you.

Happily, we are able to share our refinements and additions to the Fortran code with the community. We are using a git repository locally so there is a question as to how best to share our code: ideas are welcome.

We are also able to contribute our ObjexxFTK Fortran assertion and unit testing system for use with EPx if that is of interest to the community. We could add sample usage for them in our repository and share that if people want to see what it will look like.

We have begun by bringing the 8.0.0.008 code into the epx_dev directory organization and setting up GNU make based build systems for MinGW GFortran and Intel Fortran on Windows and GFortran on Linux.

We are currently going through an intensive testing process with the aim of finding and cleaning up any problems and attaining a high level of confidence in the code correctness. We are doing this in multiple passes:

1. Option variants with multiple compilers to reveal any issues in the code
2. Static testing with Intel's XE 2013 static analyzer and our own tools
3. Dynamic testing via test cases run with max debugging checks on multiple compilers to catch runtime issues such as use of uninitialized variables or array bounds violations that static testing can't catch. If people have test cases geared toward fast execution that gives good code coverage it would be great to get those.
   

Step 1. is just about complete and so far we have found just a few issues with the code that could affect results, which is a good sign. There are the typical sorts of minor things like the use on non-standard (but common) extensions, using single precision literals in a double precision context. There are 2 bugs that would benefit from group input since the intent and thus best fix are not completely obvious to someone new to the code like me. I will post those in separate replies to avoid making this posting longer.

Happy to discuss any of this,

Stuart Mentzer

[Stuart Mentzer]

So the first EnergyPlus 8.0.0.008 bug we found is in DataHeatBalance at line 1606. The constructor of the ZonePreDefReplyType instance is missing two values that would go at the end of the first line:

   ZonePreDefRepType(.false.,0.0,0.0,0.0,0.0,9.9d9,0.0,9.9d9,0.0,9.9d9,                   & !

It appears that the intent was to use the default initializer values so the missing values would be another 0.0,9.9d9 pair. But if the intent was to default construct why is this explicit constructor present?

We have removed the explicit initializer in our code as an interim fix but getting to a consensus on this would be good.

Thanks,
Stuart

[Stuart Mentzer]

The next bug is is DaylightingManager.f90 at line 2098.

TVISIntWin is used but never set in FigureDayltgCoeffsAtPointsForSunPosition. TVISIntWinDisk is set by call to POLYF but TVISIntWin is never set. The intent is unclear to me.

Suggested fixes?

Stuart

[Neal Kruis]

Stuart,

This is great information! I am going to try to respond in separate, more topical threads, but in general, we are still ironing out the process of submitting bug fixes. In the meantime, do you mind sending me a URL to clone your repository? I can use it to review the changes and then post any changes to the SourceForge repository.

As far as the two bugs go, it seems that they do not cause any problems for either the EPx build process, or (as far as I know) the EnergyPlus team release build process. I'm guessing this has something to do with using different compiler flags. I will start a new thread to discuss this.

Thanks,

Neal

[Stuart Mentzer]

Unfortunately, many classes of Fortran bugs do not prevent building and many do not generate warnings even when all compiler warnings are enabled, so the fact that a code builds is not an indicator of correctness. Additional testing is required to ferret out problems in Fortran.

Static testing of the EnergyPlus code has turned up quite a number of other problems, although few seem likely to affect typical runs. These fall under categories such as actual or potential bounds violations, use of uninitialized variables, possibly not setting the return value of functions, missing constructor arguments, unsafe use of OPTIONAL arguments, modifying INTENT(IN) arguments, possible divide by zero, and so forth. I am fixing or flagging these in my repository as I go. Once we have a reporting process I'm happy to enter them although there may be too many to practically ticket each separately.

There are also some practices that are best avoided, such as exact comparisons between floating point values: these should be reviewed at some point.

Stuart

[Stuart Mentzer]

TarcogComplexFenstration:

Around lines 4114 and 4167: con is used uninitialized
  hg(i) = Nu(i) * con / gap(i)

The intent isn't clear. I zero initialized con as an interim patch.

[Stuart Mentzer]

ElectricPowerGenerators: GetFuelCellGeneratorInput:

Can continue when "severe error" conditions like (NumFuelCellPMs <= 0) and (NumFuelCellAirSups <= 0) occur, which will use thisFuelCell uninitialized or set from a previous block.

Either the errors need to be made Fatal or the code reworked to eliminate this exposure.

[Stuart Mentzer]

AirflowNetworkSolver: PresProfile and PStack:

Bounds violations for 2-element arrays in a number of locations (when k>2 or, in one instance, i>2). Marked with !Objexx:BoundsViolation comments in my git code.

The intent is not obvious and it looks like a significant reworking is needed.