Hi @GaoxingZheng,
Sorry this isn’t working for you. I’ve been looking into this, and I can reproduce the error using 3.0.3. This doesn’t happen on our current master branch though (soon to be released as 3.0.4), and I’ll freely admit I’m not sure why that is.
The main reason is that the DW scheme information is supposed to be stored in the JSON sidecar file (dwi_pad2_pe_0.json) at this point:
Command: mrconvert dwi_pad2.mif dwi_pad2_pe_0.nii -coord 3 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 -strides -1,+2,+3,+4 -json_export dwi_pad2_pe_0.json
and this is then fed back in during the subsequent conversion back to mif:
Command: mrconvert dwi_pad2_pe_0_applytopup.nii dwi_pad2_pe_0_applytopup.mif -json_import dwi_pad2_pe_0.json
But on 3.0.3, the JSON file doesn’t contain the DW scheme information. Works fine on the master, though I can’t identify a single change in the code that would explain this… 
In the meantime, the simplest thing is just to make sure your input mif file already contains the correct DW information:
mrconvert ${Output_Folder}/Tracking/degibbs.mif ${Output_Folder}/Tracking/DWI_preproc_in.mif -fslgrad ${Output_Folder}/Tracking/AP_PA.bvec ${Output_Folder}/Tracking/AP_PA.bval
and use the resulting ${Output_Folder}/Tracking/DWI_preproc_in.mif as your input to dwifslpreproc without the -fslgrad option. That should work – though you may encounter a different bug in the process (also fixed on master, but not yet released… 
).