Additional information: I only tested Terrain Flattening with External DEM because of the TF artifact issue with auto downloaded Copernicus or SRTM DEMs. My tests were on CentOS 7, and several versions of SNAP: 7.0.2, 8.0.3, and 8.0.9, which all returned the same results.
I now have compared Terrain Flattening and SAR-Simulation products produced with both External DEM and autodownloaded Copernicus DEMs. The autodownloaded DEMs result in the TF issue noted above, but sufficient information is visible that suggests the SAR-Simulation registration to the image, and the qualtity of TF are different than when using External DEM. It was entirely coincidental that use of External DEM for SAR-Sim and TF of descending passes appeared aligned/correct, and that only ascending passes required the DEM shift.
This a mess! Using the same DEMs via Autodownload, and as External DEMs produce different results which I had previously noted relative to auto downloaded DEMs here, and about inconsistent results here. Once this DEM issue is fixed, I’ll need to revisit the registration of SAR-Sim products, and the quality of TF.
@jun_lu If gdalbuildvrt with the default nearest resampling is used with an extent defined by -te, this can introduce a subpixel shift in an image. I was thinking SNAP might use gdalbuildvrt to combine the autodownloaded DEM tiles. We have encountered the subpixel shift effect ourselves.