foreach 的神秘错误
在我第一次尝试 foreach 时,我遇到了这个错误:
Error in function (handle) :
no function to return from, jumping to top level
我为每个工作人员得到一个错误。
我正在使用 doMC/多核后端。
起初我认为这是由我的 foreach 调用中的函数试图发送到控制台作为副作用的文本进度条引起的,但在关闭它后我仍然收到错误。尽管存在错误,评估仍在继续,所有仓鼠似乎都在跑步。里面的函数恰好是 reclass() 库(栅格)中的 calc()。谁能猜出这可能意味着什么?我想我会在等待输出是否有效时询问。
更新
这是代码的核心:
foreach( cover= names( classes), .packages= "raster") %dopar% {
class <- classes[[ cover]]
calc( mlct$pri,
function( pri) {
ifelse( is.na( pri), NA,
ifelse( pri ==class, 1, 0))
},
filename= paste(
mlctName,
paste( cover, ".tif", sep=""),
sep="_"),
overwrite= TRUE, ...)
}
如果不熟悉library( raster)
,它提供了一种巧妙的机制,可以与地理空间栅格数据集进行交互,而不必将它们放入内存中。这些函数逐块读取和写入数据。在这种情况下,工作人员都从相同的源数据读取,但写入单独的输出文件。我想知道这个文件 I/O 是否与上面报告的(看似良性的)错误有关。
现在它已经吐出了我期望的所有新文件,但这出现在控制台上:
GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed, this is probably not a valid IFD offset
尽管核心很安静,但解释器提示符没有重新出现。我猜想,文件 I/O 不知何故出了问题的另一个线索。有什么想法吗?
On my first foray into foreach I am getting this error:
Error in function (handle) :
no function to return from, jumping to top level
I get one of these for each worker.
I am using the doMC/multicore back end.
At first I thought this was caused by the text progress bars that the function inside my foreach call was trying to send to the console as a side effect, but I still get the error after turning that off. Despite the errors the evaluation continues and all hamsters appear to be running. The function inside happens to be calc() from library(raster). Can anyone surmise what this might mean? I thought I would ask while I wait to see whether the output is valid.
reclass()
Update
here's the heart of the code:
foreach( cover= names( classes), .packages= "raster") %dopar% {
class <- classes[[ cover]]
calc( mlct$pri,
function( pri) {
ifelse( is.na( pri), NA,
ifelse( pri ==class, 1, 0))
},
filename= paste(
mlctName,
paste( cover, ".tif", sep=""),
sep="_"),
overwrite= TRUE, ...)
}
In case of unfamiliarity with library( raster)
it provides a clever mechanism for interacting with geospatial raster data sets without having to snarf them into memory. The functions read and write data block by block as they go. In this case the workers are all reading from the same source data but writing to separate output files. I wonder if this file I/O has anything to do with the (seemingly benign) errors reported above.
Now it has spit out all of the new files that I expected but this appears on the console:
GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed, this is probably not a valid IFD offset
and the interpreter prompt is not reappearing despite the fact that the cores are quiet. Another clue that file I/O has gone awry somehow, I would guess. Any thoughts?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我想我已经有了答案。我在 GDAL-dev 列表上从 Even Rouault 那里得到了一些帮助。请参阅 GDAL-dev 档案中的此主题 (也可以通过 Nabble 获得)。如果他出现了,他应该得到这个答案的荣誉,而不是我
。问题的关键是我必须将光栅数据集的文件名传递给 foreach 工作人员,并在 foreach 闭包中重新实例化 raster() 对象。每个工作线程都需要有自己的 rgdal 句柄来读取输入数据。
新代码如下所示:
现在 fracDoparFun() 返回一个文件名列表,这些文件名是工作人员生成的输出,然后由 brick() 将其收集到单个多频段结果中 函数。
感谢大家的关注。我希望我不会过早地关闭它,但我已经对其进行了测试,并且我想捕捉我所学到的东西。
I think I have the answer. I got some help from Even Rouault on the GDAL-dev list. See this thread in the GDAL-dev archives (also available through Nabble). If he ever comes along he should get credit for this answer, not I.
The crux of the matter is that I have to pass filenames of raster data sets to foreach workers and re-instantiate the raster() objects within the foreach closure. Each worker needs to have its own rgdal handle for reading the input data.
The new code looks like this:
Now
fracDoparFun()
returns a list of filenames that are the outputs generated by the workers that are then collected into a single multi-band result by thebrick()
function.Thanks for taking a look everyone. I hope I'm not closing this prematurely, but I have tested it and I wanted to capture what I had learned.