我正在使用群集并行生成数千个带有R的CSV。大多数CSV都没问题。然而,他们中的一些人遇到了令人难以置信的问题,因为我不知道如何复制。
以下CSV摘录可能最能说明问题:
"id","z1","z2","t","t0","d","runtime"
1,39.0107766942301,37.6647641938649,1,0,0,14.817
1,48.7828967951132,27.8792166300373,2,1,0,14.817
.
.
.
1000,52.5137565503309,31.3138744122258,34,33,0,14.817
1000,48.7163379096316,30.5135773682921,35,34,0,14.817
1000,48.7682481798877,30.4314581446581,36,35,0,14.817
.785747185412,28.2949871247436,19,18,0,16.1849999999999
841,61.5267561510041,21.9846948710836,20,19,0,16.1849999999999
841,50.8342061013446,29.4827369026791,21,20,0,16.1849999999999
.
.
.
与前1000个id
对应的行应该在文件中。在最后一个id = 1000
文件之后,从缺少id
变量的下一行开始,数据似乎完全来自不同的数据文件,因为对于每个文件,{{1}变量应该是常量。
我的代码可能存在问题。似乎有一些迄今为止尚未发现的数据框合并正在进行中。但是,我的问题不在于我的编码不足之处。我的问题是关于如何使用R生成一个写入的CSV,中间有一行,其中一列比所有其他行少一行。
用于写入文件的函数是runtime
修改的
我明白了。文件名分区错误。很抱歉浪费每个人的时间,但很高兴我学到了一些关于SNOW的知识。
答案 0 :(得分:1)
我注意到snow
包用于并行计算的行为相同。如果两个进程写入同一文件,则会发生这些错误。计算时间越短(写入文件的时间越长)就越有可能获得。
如果您通过某个循环或函数运行并行化,请在其中调用Sys.getpid()
并使用paste()
构建文件名。
这适用于我的应用程序。每个工人一个文件,没问题。