Discrepancy in MVPA between different input methods about ggir HOT 4 OPEN

I assumed that GGIR uses the same code for both data formats.

1. I am only wondering now whether this recent commit is causing trouble by attempting to look for and impute gaps twice when rmc.imputegaps = TRUE.

2. Could it be that the difference is in how you created the csv file? In GGIR the gt3x file is read with default read.gt3x arguments https://github.com/wadpac/GGIR/blob/master/R/g.readaccfile.R#L275-L276 and without using the imputezeros or clean options that read.gt3x offers.

3. The MVPA extraction happens much further down the line and is the same code for all data format. So, I think that differences must be explained by the raw data itself or by how it is read. It may be good to compare the output of read.myacc.csv() to read.gt3x() output:

• Do you see any obvious synchronisation problems when you plot the signals on top of each other, e.g. time zone difference?
• Are time series the same length?

Note that saving numeric data to csv can in itself introduce some tiny rounding errors.
If that does not lead to a clear explanation then we may need to try comparing the epoch level metrics produced by GGIR part 1 ... to get these load the .RData file form the output subfolder meta/basic folder and inspect object M$metashort. These are the metric values.

from ggir.

@pinweichen have you tried running one of the data files where you see this issue through the latest version of GGIR?

I know you said you need GGIR 3.0-0 for your project, but there have been a few changes to raw data handling since last October when that version came out.

from ggir.

Thank you Lena and Vincent for responding.
To Vicent's questions:

1. The duplicated steps of time gap imputation do not affect the result. The discrepancy results still exist when both rmc.imputegaps = FALSE and rmc.doresample = FALSE. I also was testing on GGIR 3.0-0.

2 & 3. I've compared all three types of raw data and compared them row by row: 1. load gt3x using default gt3x load method, 2. load my customized version of csv using fread, and 3. load the csv file using read.myacc.csv function from GGIR. All three data are identical when loaded. Time series are in the same length.

I also compared the part 1 meta result by loading the meta/basic file. I notice in C variable, the spheredata are different. So are the scale, and offset. (Original_C = gt3x result. std_C = custom csv result.)

I've also tested the version when I turned on rmc.imputegaps = TRUE and rmc.doresample = TRUE.

It seems like somewhere in the calibration steps creates these errors. Are those calibration steps for custom csv handled differently than the gt3x? Where can I dig more about the potential cause? I do have some header information missing since it didn't read directly from gt3x. What information in the header could be important for the calibration steps?

To Lena,
I haven't adapted the GGIR 3.1-2 version yet. I did make some changes in the read.myacc.csv header reading portion in my current pipeline. I will need to move those changes with the 3.1-2 version before I test the custom csv. However, I've tested the output from read.myacc.csv. It produces the same result as if I read the gt3x.

Thank you for your time and patience.

from ggir.

If you insist on using an older version of GGIR then you also have to life with all the bugs and inconsistencies it had.

If you want the issue to be fixed use the latest GGIR version.

If the issue is still present in the latest GGIR version then please clarify as this is currently unclear to me.

from ggir.