Temporal program stuck in infinite loop

I am running SMOKEv4.5 after porting a working framework to a different server. Currently I am running on the new server in a QSUB interactive session on an intel node. Not sure if that matters. I am starting with nonroad, and when temporal runs, it reports:

 >>--->> WARNING in subroutine envintc
 Value for G_STDATE not an integer : 'ram', returning default  0

 Value for G_STTIME:  80000
 Value for G_TSTEP:  10000
 Value for G_RUNLEN:  250000
 Value for PROMPTFLAG:  N returning FALSE
 Using default value         0  for query:
 "Enter simulation starting date (YYYYDDD)|(YYYYMMDD)"

 >>--->> WARNING in subroutine GETDATE
 Date is out of acceptable modeling range

 Using default value         0  for query:
 "Enter simulation starting date (YYYYDDD)|(YYYYMMDD)"

and then goes into an infinite loop, repeating the last two blocks of messages.

G_STDATE is set to a proper integer (2019151) and this is confirmed when echoing the value after sourcing the ASSIGNS file.

Does anyone have any idea why this is occurring?

Turns out this problem was due a problem with the ASSIGNS file that, when sourced (the second time) by smk_nonroad.csh, was setting variables to blank. Though, it is concerning that temporal would allow itself to get stuck in an infinite loop and thus grow log files indefinitely.

Hi Farren. Thanks for sharing your findings. Can you provide more details? Are you using EPA platform package setup? Right? I would like to understand the core of problem to prevent it from happening again.

Hi BH, the ASSIGNS file had been altered to use $1 (first argument of the master script) as date input. I should’ve caught this right away, but for some reason when the ASSIGNS file was sourced in the master script, $1 was passed through successfully so all other programs ran fine. However, when the master script called smk_nonroad.csh which then sources the ASSIGNS file a 2nd time, the $1 was identified as blank, and temporal went into the infinite loop asking for G_STDATE to be defined.

Thanks for the update Farren. I will watch out on this issue.