Variable declaration in parallel sh -c …

Your problem has nothing to do with bash. In fact, since you're telling parallel to run sh, you may not even be using bash.

The issue is that parallel is not really a drop-in replacement for xargs, as its documentation indicates. Instead, it accumulates its arguments into a single string (with spaces between them) and then interprets that as a series of commands. So, in your case, you have:

sh -c 'name="{.}"; echo {.} ${name%.*}.tpr'

which is interpreted as

sh -c 'name="{.}";
echo {.} ${name.*}.tpr

Since those are two separate commands, and the first one executes in a subshell (sh -c), $name is not set in the second one.

Now, you could add pretty well anything to the beginning of the string, such as true:

sh -c 'true; name="{.}"; echo {.} ${name%.*}.tpr'

That will be interpreted as:

sh -c 'true'
name="{.}"
echo {.} ${name%.*}.tpr'

In this case, the call to sh is essentially a throw-away; then name is set in the environment maintained by parallel and finally echo is called with name set.

So it would appear that the easiest solution is simply to get rid of the unnecessary call to sh:

find 1st 2nd 3rd -name '*.xtc' -print0 |
parallel -0 'name={.}; echo {.} "${name%.*}.tpr"'

Note: Based on a hint given by @StephaneChazelas, I removed the quotes around {.} and added them around ${name%.*}.ptr. parallel does its own quoting of its own substitutions, which interferes in some odd ways with explicit quotes. However, it does not add quoting to shell substitutions, which should be quoted if there is any possibility of the substitution being word-split.

Another option, if you really want to use a subshell for some reason (or a particular subshell), would be to use the -q option:

find 1st 2nd 3rd -name '*.xtc' -print0 |
parallel -0 -q sh -c 'name="{.}"; echo "{.}" "${name%.*}.tpr"'

Note: As above, I adjusted the quotes. In this case, the explicit -q suppresses the quoting of substitutions, so you have to quote them explicitly. However, this is a textual quotation, which is less accurate than shell quoting; if the substitution includes a double-quote character, that character will not be escaped, so it will close the explicit quotes, breaking the command line. For this, amongst other reasons, the -q option is discouraged.