GGIR version 1.5-7 bug

[JianWang2016]

Dear Vincent,

Per your instruction on forum at https://groups.google.com/forum/#!topic/RpackageGGIR/kjJMePHDU_Q,
I am submitting an issue here.

The bug of src/numUnpack.cpp is NOT fixed in g.inspectfile(), g.getmeta(), g.calibrate() and a number of other places using the above functions.

Your attention is greatly appreciated.

library(GGIR)
I = g.inspectfile(datafile)
Error in Rcpp::sourceCpp("src/numUnpack.cpp") :
file not found: 'src/numUnpack.cpp'
In addition: Warning messages:
1: In normalizePath(dirname(file)) :
path[1]="src": No such file or directory
2: In normalizePath(file, winslash = "/") :
path[1]="src/numUnpack.cpp": No such file or directory
I = g.getmeta(datafile)
Error in Rcpp::sourceCpp("src/numUnpack.cpp") :
file not found: 'src/numUnpack.cpp'
I = g.calibrate(datafile)
Error in Rcpp::sourceCpp("src/numUnpack.cpp") :
file not found: 'src/numUnpack.cpp'

[vincentvanhees]

thanks Jian, I am aware of this and it will be fixed in the next release, which I aim to upload later this week

[vincentvanhees]

Now in release 1.5-8 here on github https://github.com/wadpac/GGIR/releases/tag/1.5-8
I will upload this to CRAN later this week

[JianWang2016]

Thanks so much Vincent for getting a new release so quickly.
It looks great so far!

[vincentvanhees]

Looks good so far. The 991997 blocks are not the same 'blocks' as printed in the console. It is a bit ugly and confusing i have to admit, but g.cwaread defines a block in the data as a segment of about 300 samples, while the block numbers other parts of GGIR are printing in your console are the blocks of data loaded, with about 12 hours of measurement per block for the autocalibration part and 24 hours per block in the get meta data part. So, this should not take much more than 15 minutes or so, depending of course on sample frequency and measurement duration.

[vincentvanhees]

maybe I should rename the latter 'blocks' to 'chunks', because there is a function argument in GGIR called chunksize which relates to these larger blocks. In that way I can reserve the terms pages and blocks for everything that happens at the level of reading in the data from the cwa or bin files, and reserve the term chunks for the process of putting large 'chunks' of data in memory to process them. Related terms like window, segment, period, epoch, and bout are already used elsewhere in the code. I will create a seperate issue for it now.

[vincentvanhees]

... this is a response to a post that was deleted...

My guess for now is that the code struggles with the folder name 'output' because GGIR creates a folder name 'output_datasetname' and later on searches for it... I would have to investigate this as it would be good if you could use any folder name you like.

As a quick fix, can you rename the argument for outputdir to:
outputdir = "/myfolder/myfolder2/myfolder3"

Next, your part2 output should be stored as subfolder inside:
'/myfolder/myfolder2/myfolder3/output_ax3TestDataCwa2'

[JianWang2016]

This strategy works perfectly! Thanks much.

[vincentvanhees]

Ok, I updated the folder names. Did you delete your own comment? It is not going to be very helpful for others to understand this conversation if you remove your own comments

[JianWang2016]

Vincent, I am so sorry.
Here is the summary of what I reported:

The phrase "output" is contained in my outputdir path, leading to confusion in go.part1. As a result, contents which are supposed to be stored within a folder under outputdir ends up in a same named folder under datadir. The program then complains the folder it needs not there.

The workaround is to avoid using "output" in the outputdir path.

Thanks much Vincent.