972110 swimming pool

Changes and additions needed to model indoor swimming pools; this work is ready for review

  
    
  
  
    Rick,
      
      The way to do features (swimming pools, movie stars, ...) more
      cleanly will require some OO refactoring of the EnergyPlus design
      -- within the current design you probably had little choice so the
      critique is not about what you did but about what the design
      forces developers to do.
      
      Stuart
      --
          Stuart G. Mentzer
          Objexx Engineering, Inc.
          Office  1.781.455.1150 x11
          Mobile 1.781.708.3872
          
        
      On 11/26/2014 9:50 AM, Rick Strand wrote:
    
    
      
      I agree that the addition of the swimming pool at this “hot spot”
      (I like that—I’m now the creator of a simulation hot spot!) is not
      conducive to faster execution.  From an algorithm standpoint, it
      was the clearest and most logical place to plug in though.  If
      there are faster alternatives that are still essentially clear as
      to what is going on, that is fine with me.
      
      
      Rick
      
      
      
        
          On Nov 24, 2014, at 6:09 PM, Stuart Mentzer <notifications@github.com>
            wrote:
          
          
            
            In src/EnergyPlus/HeatBalanceSurfaceManager.cc:
            > @@ -5141,10 +5154,14 @@ CalcHeatBalanceInsideSurf( Optional_int_const ZoneToResimulate ) // if passed in
>  					if ( surface.HeatTransferAlgorithm == HeatTransferModel_EMPD ) {
>  						CalcMoistureBalanceEMPD( SurfNum, TempSurfInTmp( SurfNum ), TH22, MAT( ZoneNum ), TempSurfInSat );
>  					}
> -					Real64 const TempTerm( CTFConstInPart( SurfNum ) + QRadThermInAbs( SurfNum ) + QRadSWInAbs( SurfNum ) + HConvIn( SurfNum ) * RefAirTemp( SurfNum ) + QHTRadSysSurf( SurfNum ) + QHWBaseboardSurf( SurfNum ) + QSteamBaseboardSurf( SurfNum ) + QElecBaseboardSurf( SurfNum ) + NetLWRadToSurf( SurfNum ) );

            TempTerm and TempDiv are pulled out into variables
              because those quantities were being computed twice each
              and they are not simple/cheap expressions. If you search
              for them you'll find the other uses a few lines down.
              While I was pulling out the divisor anyway I made it into
              a multiplication but that was not the primary purpose. The
              change saves 15 array lookups, 11 +/-, and one multiply
              every time you pass through that code. Sometimes I'm
              scrounging for small performance gains in hot spots and
              sometimes these silly changes pay off nicely.
            If the new if block breaks the ability to reuse these
              quantities then there is no point to defining them for
              one-time use. If the surface is "almost never" a pool then
              computing them will still pay even though you occasionally
              don't use them -- yes that is hackish so decide whether
              you can live with it. You could get fancy and define them
              at the higher scope but with a ( surface.IsPool ?
                0.0 : <formula> ) conditional so that you
              don't pay for the expensive computation unless it will get
              used.
            This addition of features by conditionals in hot spot
              code is not conducive to performance, as we know.
            If I haven't been clear enough let me know. I'm happy to
              rework this code segment if you tell me which version to
              start from.
            —
              Reply to this email directly or view
                it on GitHub.