Hi Julie,
I’m probably not the best person to answer your queries, but in the interest of giving @rsmith a break, I’ll give it a shot…
For your Q1: if I understand correctly, your concern is that the when running eddy_cuda with slice to volume correction, you get a message relating to the assuming slice encoding direction, that you don’t get when running eddy without slice to volume correction. But you seem to be confusing the phase-encode direction (which topup needs to know to estimate susceptibility-induced distortions) and the slice direction (which eddy needs to know for the slice to volume correction). Knowing the phase-encode direction isn’t enough to figure out the slice direction, so this is different and necessary information. The program is informing you that it’s assuming your slice direction is inferior-superior – but (rightly) warning you that this is just an educated guess.
Your regular eddy run without slice to volume correction simply doesn’t need to know the slice direction, and so dwifslpreproc won’t even bother trying to figure it out – and you won’t get that warning.
For your Q2: I’m not sure I see the problem (?), but it looks like you’re concerned that the behaviour is not as expected based on an old post from May 2019? But in that same post, @rsmith explicitly states:
Which basically says that the behaviour in future versions will be different, specifically to address the issue you’re referring to. Back in May 2019, we were still on version 3.0_RC3 – we’re now on 3.0.2, and this issue was addressed at the time, which your results seem to confirm? Let me know if I’m getting the wrong end of the stick here…
For your last PPS issue, I’m not sure about this one, I’ll have to handball that one over to @rsmith… But given that the problem is that it’s trying to copy a file onto itself, I doubt this is much to worry about.