minor bugfixes on aa_export_toBIDS - #196

It seems quite all right, but I am not so sure about

I could be wrong but don't we want to keep src? In my test pipeline src is the .nii that gets generated at the end of aamod_covert_epi.

I discovered this problem by running export_toBIDS twice. On the second run, the copyfile crashes because src was deleted from aamod_convert_epi in the previous pass.

It depends on the use case:

1. If there is no dummy scan, then src is indeed the converted epi. In that case, src_dummy will not be created and nothing will be deleted.
2. If there is any dummy scan, then src and src_dummy point to the temporary file (dummy + epi) and the dummy file, respectively,

Are you able to run export_toBIDS twice on your data? This is what alerted us to the problem.

Yes, I can run aa_export_toBIDS twice on e.g. both the aa demo and the bids114 datasets. However, both requires some tweaking:

• aa demo has a short subjectname, which causes

  automaticanalysis/aa_toolbox/aa_export_toBIDS.m

  Line 120 in 1a68e1d

  if ~isequal(suboutname(1:4),'sub-')

  crash, so it has to be omited.
• bids114 demo has not got a full header which causes

  automaticanalysis/aa_toolbox/aa_export_toBIDS.m

  Lines 256 to 258 in 1a68e1d

  	'PhaseEncodingDirection',[...
  	sliceaxes{cell_index(sliceaxes(:,1),deblank(hdr.InPlanePhaseEncodingDirection)),2}{aas_get_numaris4_numval(hdr.CSAImageHeaderInfo,'PhaseEncodingDirectionPositive')+1}...
  	],...

  crash, so they have to be omited.

However, both issues are irrrelevant regarding the current PR. Still, they should be fixed, of course.

Yes, I can run aa_export_toBIDS twice on e.g. both the aa demo and the bids114 datasets.

Interesting. I'll look into what is peculiar about my data (which crashes)...

Okay, finally got some time to look into this. I think the line in question should actually read:

copyfile(src,dest); gzip(dest); delete(dest); if (exist('src_dummy','var') && ~isempty(src_dummy)), delete(src); clear src_dummy; end

The hiccup is src_dummy gets created by checking if any of the modules have a "dummyscan" output stream (line 225) -- this will be true for any pipeline that contains aamod_convert_epis even if you don't actual create any dummyscans. So we need an additional check if scr_dummy is empty. That fixed the crash on my machine.

This looks good to me. Do you want to update the PR?

This looks good to me. Do you want to update the PR?

Nah -- it was my screw up.

I'll push a correction...