2011-03-24 – NRC – Fukushima Daiichi – Issues with RASCAL During Fukushima Response

2011-03-24-nrc-fukushima-daiichi-issues-with-rascal-during-fukushima-response

Leave a Reply

Your email address will not be published. Required fields are marked *

From:
Sent:
To:
Subject:
Attachments:
George Athey
Thursday, March 24, 2011 5:22 PM
Brandon, Lou; PMT02 Hoc; PMT11 Hoc
Summary of RASCAL errors and suggested workarounds
Fukushima RASCAL errors.pdf
PMT Dose Assessors
Please see the attached PDF for a brief write-up of some of the errors you have been encountering with RASCAL during
the Fukushima response and some possible workarounds or fixes. I will be in the office on Friday, March 2 5th so if the
document needs expansion or correction please let me know.
George Athey
Athey Consulting
(304) 725-8834
[email protected]
1
DB 400 of 696
Issues with RASCAL During Fukushima Response
To: PMT Dose Assessors and Meteorologists
Thanks to all who are giving RASCAL such a thorough workout. All the feedback, errorreporting,
and suggestions for improvements are welcome and appreciated.
Following is a summary of some of the problems that have been occurring with RASCAL and
what you can do about them.
Problem: Total crash of the STDose model
Symptoms: The program shuts down completely; sometimes with an error message and
sometimes without. This happens when trying to do a very long calculation (e.g. 48 hours) with a
large release rate (e.g. total failure or 100%/hr).
Cause: The transport and diffusion puff model that calculates to the longer distances (10/25/50
mi) is having problems with the long durations. We are not sure why the module is crashing but
the developer is looking into things.
Workarounds:
” If all you need is the source term to export to NARAC, then run with “Close-in only”
selected. This will avoid the puff model but still generate the full source term file.
* If you need to see results to distance, reduce the calculation time to say 24-32 hours. With
large release rates most of the material has been released by 10-12 hours anyway and all
that gets added to dose with the longer calculation time is groundshine.
* If you absolutely need to do 48 hours, try using a lower leak rate. Try 50%/hour. You will
still get all the material out it will just be at a slower rate. Overall doses should be about
the same.
Problem: Error 13, Type mismatch
Symptoms: This was first reported on Monday morning on PMT02. Restarting RASCAL did not
help. The error was occurring because RASCAL could not delete the files in its temporary folder
(\STDTemp). We tried manually deleting them and then restarting RASCAL. The files
reappeared somehow; not sure why but it may be a Windows XP issue. A similar issue appeared
on Thursday on PMT 11.
Fix: Rebooted the computer. Then, after restarting RASCAL, selected New Case from the file
menu. This forced a fresh cleanout of the RASCAL temporary folder. I don’t think that
RASCAL needs to be reinstalled – although that may also work because it rebuilds the folders.
Thursday March 24, 2011
DB 401 of 696
Problem: Timing of Sprays off was changing doses
Symptom: Moving the time when sprays were Off in the release pathway definitions changed
the results. A user set the Sprays Off event in the release pathway to the reactor shutdown time
(instead of the default of core damage time). Since the sprays are off by default this should not
have made a difference. However, it radically changed the doses. We are not sure why this is
happening. It appears related to the timing in the source term model that controls the removal
and reduction processes. A developer is looking into the issue.
Workaround: Leave the first spray event paired with the first leak rate event (whether on or
off). This is how the initial release pathway is defined with a new case. It is OK to add spray
events later. Just don’t stick in events earlier than the first leak rate event.
If you need more information on any of the above do not hesitate to call or e-mail. I will be out
of the office on vacation starting Monday, March 28th. I will be back in the office on Tuesday,
April 5tl. I will be checking e-mail and voice mail (office and cell) so I can provide some support
if needed. Please continue to report any problems with RASCAL and include as much detail as
possible to help us duplicate the conditions.
George Athey
(304) 725-8834 office
(b)(6 cell
[email protected]
Thursday March 24, 2011
DB 402 of 696