Dtstep development of an integer time step algorithm
1 / 21

DTSTEP: Development of an Integer Time Step Algorithm - PowerPoint PPT Presentation

  • Uploaded on

DTSTEP: Development of an Integer Time Step Algorithm. George L Mesina INL David L Aumiller BMPC. September 2010. Outline. Background and issues Integer time step Solutions and implementation Testing Conversion. Background: PVM Coupling Time Step Methods.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'DTSTEP: Development of an Integer Time Step Algorithm' - milos

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Dtstep development of an integer time step algorithm

DTSTEP:Development of an Integer Time Step Algorithm

George L Mesina


David L Aumiller


September 2010


  • Background and issues

  • Integer time step

  • Solutions and implementation

  • Testing

  • Conversion

Background pvm coupling time step methods
Background: PVM Coupling Time Step Methods

  • Synchronous coupling requires all coupled codes to use the same dt.

    • All codes suggest dt to the Executive every time step

    • The Executive limits dt based on the halving/doubling scheme

      • dt = DTMAX(Exec)/2k where dt <= smallest suggested dt.

  • Asynchronous coupling only requires codes to arrive at an Executive mandated time target. Can use own dt, DTMAX, DTMIN, etc.

    • ParallelAsynch, each code marches independently to target

    • SequentialAsynch, one code marches to target, sends data to other; other marches to target.

Background pvm coupling thermal hydraulic methods
Background: PVM Coupling Thermal-Hydraulic Methods

  • Explicit coupling exchanges data at each coupling time.

    • Simple method that is numerically unstable for many situations.

  • Semi-implicit coupling exchanges extra data at each time step to add stability.

  • Only certain combinations of time step methods and thermal-hydraulic methods are permissible.

Principal issue time step inaccuracy issue
Principal Issue: Time Step Inaccuracy Issue

  • With 64-bit floating point variables on an Opteron chip

    • Accurate to approximately 14 digits

    • The final value of timehy = 1005.0000000745, not 1005.0 exactly.

      • This is inaccurate in the 12 digit.

  • Inaccuracy builds up with longer time intervals.

  • Such inaccuracy caused PVM-coupled codes to deadlock (hang).

    • For example, one code would hit a time target and send the proper message while the other would step past it and eventually send a totally different message to the first code.

  • Often these hangs were caused by special cases, e.g. velocity flip-flop.

  • T=1000.0; dt=0.005

  • Do 10 j = 1, 1000

  • 10 timehy = timehy + dt

Sources of pvm communication issues
Sources of PVM Communication Issues

  • Asynchronous codes can have different DTMAX and DTMIN.

    • Can cause time disparity for floating point sums.

    • Original solution was to create “epsilon-tolerance if-tests”

  • Synchronous RELAP5-3D

    • Time targets were supplied, but change of timecard was not.

      • RELAP5-3D DTSTEP fundamental algorithm required end time to operate correctly.

    • Both Executive and RELAP5-3D DTSTEP routines calculated synchronous cumulative times and time-based actions.

      • Produced time discrepancies that deadlocked the machine.

  • If (abs(timehy – target) <= eps) TAKE ACTION

If DTMIN <= eps, can trigger action beforeactual target.

If eps too small, can step right overtarget.

Summary of dtstep subroutines and issues
Summary of DTSTEP Subroutines and Issues

  • Floating point inaccuracy caused trouble hitting time-targets exactly

    • Especially problematic for PVM communications

    • General solution is integer time step

  • There were other algorithmic and implementation errors

    • These will be listed later with individual solutions

  • DTSTEP did too much for one subprogram

  • It was very difficult to read and understand

    • Too many jumps

    • Logical variables with non-mnemonic names

    • Too many pre-compiler directives and conditional coding

    • Almost no internal documentation

Original relap dtstep flow simplified
Original RELAP DTSTEP Flow (Simplified)

PVM Explicit Exchange

Parallel or Seq, synch or asynch


Normal &1st time only

New Time Targets

Optional PVM Semi-imp. rcv, New time targets


(9 kinds)

Screen, plots, minor, major, restart, GUI

Abrupt Changes

Repeat with same dt, halve/double, terminate transient

User Interfaces

Time step control

dt-stretch, Courant/mass error,dt >= DTMAX/2k

Gather Statistics

New Advancement

End timecard or transient, SS check

Time step selection

Optional PVM Synch Exch, 105 card handler, advance time, EXIT

Integer time step based upon clock cycle
Integer Time Step Based upon “Clock-cycle”

  • RELAP5-3D and PVMEXEC use a timestep halving/doubling scheme that guarantees hitting integer multiples of the user’s DTMAX

    • Time targets from RELAP5-3D timecards are such multiples

    • plot, minor, major, restart edits

    • Special targets, timecard endtimes and PVM targets, need not be.

  • No step smaller than user’s DTMIN allowed. Smallest allowable dt is:

    • dtsmall = DTMAX/2n > DTMIN > DTMAX/2n+1.

  • All normal values of dt = 2k dtsmall, k=0, 1, . . . , n.

  • Dtsmall is effectively the clock-cycle of RELAP5. Always has been.

  • To convert to integer time step, use dt = Round(dt/dtsmall) = 2k.

    • Only within DTSTEP, outside DTSTEP use dt = dt * dtsmall.

  • dtsmall = DTMAX/2n

  • dt = Round(dt/dtsmall) = 2k

  • Integer time steps vs floating point time
    Integer Time Steps vs. Floating Point Time

    • Integer arithmetic is infinitely precise for add, subtract and multiply.

      • The earlier do-loop-10 example creates no summing error.

      • Error tolerances are eliminated.

    • Time, T = t * dtsmall, is more exact and slightly different from floating point calculated time.

      • Most of your RELAP5-3D results will be slightly different.

    • Integer cumulative time becomes large and requires a 64-bit integer.

      • 263 = 23 260 = 8(1024)6 > 8x(103)6 = 8x1018.

      • This is sufficient to represent 109 seconds with DTMIN = 10-9.

    • Integer Time, t, starts at zero on each successive timecard.

      • T = t * dtsmall + T(start of timecard) = floating point time.

      • Required because user can change DTMAX and DTMIN.

    • T = t * dtsmall + T(start of timecard)

    Comparison of integer and real time



    Comparison of Integer and Real Time



    dtmin=1.0e-7 n = 15


    t (seconds)




    t (cycles)




    Normal vs unusual target times
    Normal vs. Unusual Target Times

    • Normal time target, T, is an integer multiple of DTMAX

    • Unusual time target, T, is not integer multiple of DTMAX.

      • e.g. DTMAX= 0.33, Timecard end = 10.0, Assume no cuts.

        • At T = 9.9, need dt = 0.1, but 0.1 /= DTMAX/2k.

    • Unusual times are handled by using a floating point dt, which exactly reaches the unusual time, and a resynch variable.

      • The resynch variable indicates need to resynch dt and dt.

    • e.g. Dtmax = 0.004, dtmin = 1.0e-7, dtsmall =1.22e-7, target=1.00021




    t (seconds)








    Some other dtstep errors
    Some Other DTSTEP Errors

    • Explosive Doubling

      • When PVM and RELAP5-3D timecards differed

        • with R5 timecard end time exceeding PVM transient end-time,

      • The timestep could double on every timestep until the R5 timecard end time was exceeded.

      • The source was variable, NREPET.

      • The solution: PVM timecards override the RELAP5-3D timecards.

    • Penultimate timecard stop

      • Some asynchronous processes stopped at end-time of second to last timecard.

      • Cause: an error in resetting variable CURCLM in R-DTSTEP.

      • This error has been fixed.

    Some other dtstep errors continued
    Some Other DTSTEP Errors (continued)

    • Hang when subroutine HYDRO set variable, FAIL

      • R5 incorrectly sent a message that the timestep was succesful

      • Solution: Set PVM success message to repeat (as R5 repeats)

    • Hang in explicit asynchronous sequential

      • When follower received go-ahead message from leader, but had to repeat its first advancement.

        • It returned to “receive go-ahead from leader message” => hang

      • Solution: Logical variable prevents return to this receive message until time actually advances.

    • Hang from repeat condition at minimum dt (expl asyn parallel)

      • In certain cases RELAP5 DTSTEP subroutine incorrectly set dt twice the size of EXEC dt.

      • Solution: Rewrote/simplified R-DTSTEP code correctly.

    Some other dtstep errors continued1
    Some Other DTSTEP Errors (continued)

    • Stretch logic error

      • On a 2-step approach to an unusual time, first step was half the distance, but second step went to multiple of DTMAX, not endtime

      • Source: one real target time was k*DTMAX, not endtime

      • Solution: (P- and R-DTSTEP) reset ALL time targets to the unusual endtime when within one DTMAX

    • Error Messages P-DTSTEP and some PVM diagnostics were improved.

    Solutions and implementation
    Solutions and Implementation

    • Replace floating point time with integer based time.

      • Extra integer variables were created in both R-DTSTEP and P-DTSTEP

      • Replaced floating point if-tests by integer versions

      • Created internal subroutines for initializing and calculating integer time from real and vice-versa.

      • Create unifying mechanisms for quantities and processes shared by both DTSTEPS (next slide)

        • Shared module

    Some unifying implementation features
    Some Unifying Implementation Features

    • Isnormal – determines if time is normal or unusual

      • abs(1-dt/idt*dtsmallest) < 1.0e-10

      • Interpretation: dt & idt*dtsmallest agree to 10 places => dt normal.

    • Calctimehy

      • Calculate real time from certain integer time variables

      • Uses quad precision to guarantee correct conversion

    • idtmod – f95 module

      • Contains internal subroutines and data common to both P- and R-DTSTEP subroutines

        • Used by both

      • Ensures both perform same functions in same way

      • Reduces coding, increases maintainability

    Implementation continued
    Implementation continued

    • Simplified and enhanced both RELAP5 DTSTEP and PVMEXEC DTSTEP by moving portions of coding into internal subroutines.

      • Separated flowchart sections were pulled together.

      • Create internal subroutines for reused sections of code, e.g. output

      • Create internal subroutines for most precompiler-protected code

      • Replace jumps to a section of code with call of internal subroutine

    • Enhance readability

      • Determine definitions of all variables and document

      • Give mnemonic names to logical variables

      • Implement Outline-style documentation for sections of code

      • Simplify code and reduce logic paths

      • Eliminate dead code and unused variables

    Implementation continued1
    Implementation continued

    • Identified and fixed algorithmic and implementation errors

  • Created new test cases to increase coverage

    • Especially for failure conditions and PVM coupling

  • Verified that all test cases run correctly.

  • Dtstep test matrix
    DTSTEP Test Matrix

    • To fully test the relevant logic paths through DTSTEP, a matrix of over 2000 cases was constructed.

    • BASIC – 17 tests cases that cover normal, special case, and failure case and some combinations.

    Group A (34)

    Basic @ normal dt

    Basic @ minimal dt

    Group B (102)

    Group A @ minor edit

    Group A @ expl exchange

    Group A @ transient end

    Group D (2856)

    Group C R5 standalone

    Group C R5-R5 expl asynch parallel

    Group C R5-R5 semi-impl

    Group C R5-R5-R5 expl & semi-impl

    Group C R5-R5 expl synch

    Group C R5-R5 expl asynch sequ

    Group C R5 controled by Exec

    Group C (408)

    Group B w/ normal target

    Group B w/ unusual time

    Group B w/ normal then unusual target

    Group B w/ target every step

    Conversion to f95
    Conversion to F95

    • The integer algorithm was developed in version 2.4.

      • These use the old container array (FA) and equivalences.

    • All R-DTSTEP, P-DTSTEP, and related changes were ported to version 2.9.5

      • Merge issues resolved (post-2.4 development and differences in integer time implementation)

    • Conversion to F95

      • Access F95 modules, replace FA variables with module ones

    • Resolution of variable declarations

      • Issue with precompiler directive and 32-bit PVM

    • Verified again that all test cases worked correctly.