Dtstep development of an integer time step algorithm
Sponsored Links
This presentation is the property of its rightful owner.
1 / 21

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


  • 74 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

DTSTEP: Development of an Integer Time Step Algorithm

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

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

  • 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

  • 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

  • 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

  • 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

  • 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)

PVM Explicit Exchange

Parallel or Seq, synch or asynch

Initialization

Normal &1st time only

New Time Targets

Optional PVM Semi-imp. rcv, New time targets

Output

(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”

  • 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 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)


    0

    0

    Comparison of Integer and Real Time

    Example

    dtmax=0.004

    dtmin=1.0e-7n = 15

    dtsmall=1.220703125e-7

    t (seconds)

    .004

    .008

    1.00

    t (cycles)

    32784

    65568

    819600


    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

    t2=1.0021

    t1

    t3

    t (seconds)

    1.000

    1.002

    1.004

    t(cycles)

    t1

    t2

    t3=t1+dtsav


    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)

    • 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 (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

    • 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

    • 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

    • 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 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

    • 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

    • 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.


  • Login