NetCDF layer (.nc) appears flipped and rotated in QGIS

In R you can use rotate function

library(raster)
library(gdalUtils)


workdir <- "Your workind dir"
setwd(workdir)

ncfname <- "adaptor.mars.internal-1563580591.3629887-31353-13-1b665d79-17ad-44a4-90ec-12c7e371994d.nc"

# get the variables you want
dname <- c("v10","u10") 


# open using raster 
datasetName <-dname[1]
r <- raster(ncfname,  varname = datasetName)
r2 <- rotate(r)

writeRaster(r2,"wind.tif",driver = "TIFF")

I had a similar issue which I ended up solving in python using xarray:

import xarray as xr
ds = xr.open_dataset(nc_in.nc)
dtran = ds.transpose()
dtran.to_netcdf(nc_out.nc)

The QGIS raster import for netcdf uses the GDAL drivers which assume the data follows the CF conventions, and the multidimensional arrays within the data in (...Y,X) order per this:

Dimension The NetCDF driver assume that data follows the CF-1 convention from UNIDATA The dimensions inside the NetCDF file use the following rules: (Z,Y,X). If there are more than 3 dimensions, the driver will merge them into bands. For example if you have an 4 dimension arrays of the type (P, T, Y, X). The driver will multiply the last 2 dimensions (P*T). The driver will display the bands in the following order. It will first increment T and then P. Metadata will be displayed on each band with its corresponding T and P values. --per https://gdal.org/drivers/raster/netcdf.html

Your data file is in (diurnal, nlon, nlat) order, which is rotated from what the driver expects.

One way of fixing this is to transpose the dimensions to a (diurnal, nlat, nlon) order, which can be done with several tools. NCO's ncpdq from http://nco.sourceforge.net/ works well, and can also deal with flipped axes/inverted storage orders.

ncpdq -a nlat,nlon  ATS_LST_3PUUOL200208XX_0.50X0.50_CS3_LSM.nc  ATS_LST_3PUUOL200208XX_0.50X0.50_CS3_LSM_tranp.nc

...switches the dimension storage order within to (diurnal,nlat,nlon) and the /Layer/Add Raster Layer/ imports the zva "Zenith Viewing Angle" layer directly:

If you want to go further and georeference this netCDF file and add a CRS, per Displaying netCDF data with correct CRS? you could use two more NCO tools to add the CRS metadata, ncap2 and ncatted. Although the data contains 2-dimensional lat and lon variables explicitly mapping the pixels into coordinates, they do not map the dimensions to the coordinate indexes. Since in this case, the 2d variables repeat themselves along an axes, We'll ignore the 2d mapping and take a slice of each to map a coordinate variable to the dimension indexes with ncap2.

This command creates a crs variable in a copy of the transposed netcdf file to hold the CRS metadata in NetCDF form per the CF conventions https://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/build/ch05s06.html :

ncap2 -h -O -s 'crs=-9999; nlat=lat(0,:,0); nlon=lon(0,0,:)' ATS_LST_3PUUOL200208XX_0.50X0.50_CS3_LSM_tranp.nc ATS_LST_3PUUOL200208XX_0.50X0.50_CS3_LSM_transp.nc

Now, we'll use ncatted to add metadata attributes to the crs and the other variables to associate the CRS with the variables

ncatted -h -O 
    -a spatial_ref,crs,c,c,'GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_84",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.017453292519943295]]' 
    -a grid_mapping_name,crs,c,c,'latitude_longitude' 
    -a longitude_of_prime_meridian,crs,c,d,0 
    -a semi_major_axis,crs,c,d,6378137 
    -a inverse_flattening,crs,c,d,298.257223563 
    -a grid_mapping,lat,c,c,'crs' 
    -a grid_mapping,LSM,c,c,'crs' 
    -a grid_mapping,n,c,c,'crs' 
    -a grid_mapping,ncld,c,c,'crs' 
    -a grid_mapping,LST,c,c,'crs' 
    -a grid_mapping,LST_uncertainty,c,c,'crs' 
    -a grid_mapping,zva,c,c,'crs' 
    -a grid_mapping,utc,c,c,'crs' 
    -a grid_mapping,NDVI,c,c,'crs' 
    ATS_LST_3PUUOL200208XX_0.50X0.50_CS3_LSM_transp.nc

After importing a zva raster, this screenshot is overlaid on an OSM basemap.

At the widest zooms, the OSM basemaps don't project properly, but at closer zooms it renders properly:

Note that the red/green diagonal striping is due to the third dimension of diurnal being represented as two bands of a multiband color plot. You could show distinct day/night levels of diurnal by choosing a singleband rendering in Layer/Properties/Symbology. In higher-dimension netCDF files, the interactions multiply into additional bands.