Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: st: hunting for the source of an error - r(603) - Dual Core problem?
From
Jeph Herrin <[email protected]>
To
[email protected]
Subject
Re: st: hunting for the source of an error - r(603) - Dual Core problem?
Date
Thu, 27 Dec 2012 10:13:49 -0500
Are you creating the temp files? If so, and if you are using -tempfile-
to get the name of file, there may be a conflict if Stata is releasing
and reusing the file name before the OS has finished deleting the file
(can happen with very large files), which would give the error you see.
In this case, you might try ignoring the conventional wisdom and naming
the temp files yourself, with unique names, to avoid reusing file names.
Or, put a delay in the loop so the temp file has a chance to finish
deleting before Stata tries to open a new one. Just a thought.
Another idea - generally a good one anyway - is, if possible, set the
temporary directory to another drive, eg, d:\temp. Stata uses the Win
environment variable TEMP, which you can reset permanently via some Win
dialog (can't recall which). If nothing else, it will speed things up to
have the temp files on a separate drive than the one the OS is on, but I
sometimes find that under Windows unexpected things can happen in the
AppData folder.
Hope this helps,
Jeph
On 12/27/2012 8:43 AM, Ben Hoen wrote:
Hi all,
I have a relatively simple looping function that repeatedly saves and calls
up temp files while looping through each case in a dataset, which, if
successful, should take ~ 8 hours to run, though, I have yet to have it
execute properly. The last four times I have tried to run it will the full
sample I have gotten the same error:
"file C:\Users\Ben\AppData\Local\Temp\ST_0500000x.tmp could not be opened
r(603);
end of do-file
r(603);"
where x=3, 4 or 6
Each time the error has happened on a different case. The most recent three
occurred on the 794th, 25,835th and the 20,633rd cases (and before that I
had runs out to the 70,000 and 60,000th (or so) cases. There are a total of
166,181 cases.
Is it something outside my code that is likely making this occur? I am
wondering if this has something to do with a dual-core processor. I am
running Windows 7- 64bit, with an Intel Duo Core E8600 - 3.33 Ghz processor
with 8 GB of RAM, and am running Stata MP 12.1 for Windows - 64bit. BUT,
that is a GUESS (and nothing more). My thought was that this error is
occurring when the file is in use or is stored in one processor while the
other is trying to access it?
I have tried to force the error by running the code using many different
subsamples and have never been able to get it to crash, and unfortunately
breaking the sample down into smaller sample somewhat defeats the purpose of
the code in the first place (which is creating nearest neighbor weights -
using, in part, geonear(SSC)). It seems important that the error has
occurred on a different case, potentially indicating that the problem is not
with the sample.
Any ideas? Thank you in advance for any assistance/advice you can offer.
Ben
Ben Hoen
Principal Research Associate
Lawrence Berkeley National Laboratory
Office: 845-758-1896
Cell: 718-812-7589
[email protected]
http://emp.lbl.gov/staff/ben-hoen
Visit our publications at:
http://emp.lbl.gov/publications
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/faqs/resources/statalist-faq/
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/faqs/resources/statalist-faq/
* http://www.ats.ucla.edu/stat/stata/