UMEP-dev
SOLWEIG coordinates
I'm trying to run SOLWEIG, my files are in the Geographical coordinate system: BD72. However when I look at the RunInfoSOLWEIG_2024_223_0000.txt file that I got, I see this.
Where he recognizes the BD72, but the latitude and longitude are switched. Resulting in a sunrise and sunset at the wrong times leading to wrong Tmrt's in my output.
I work in Qgis version 3.40 where the coordinates in BD72 are represented as: 137196, 191038. When i put my coordinates in WGS:4326 this becomes: 51.02589°, 4.18671° At an older version of Qgis these was the same for BD72: 137196, 191038. But when put in WGS:4326 this is 4.18671°, 51.02589°
Does anyone know how to fix this? Thanks in advance!
Hm, we have not changed anything from our side (or have we @nilswallenberg ?), so it must be something on the QGIS-side. As a quick-fix, try reproject into a common CRS that we know is working, e.g. UTM.
No, we have not changed anything. Older versions of QGIS used gdal 2.x, that had swapped lat and lon, but this shouldn't be the case here. What versions of Python and GDAL do you have?
I am using Python 3.9.18, qgis: QGIS 3.40.2-Bratislava 'Bratislava' (exported) but I'm unable to find the version of GDAL. I will try the suggested quick-fix tomorrow.
I now reproject to EPSG:32631. Which leads to the correct lon and lat. But all SOLWEIG outputs seem to be night. the added picture is from 15:00, but all output times look identical.
You need to make sure to update your Python which should be 3.12. Your gdal version is found in the about section.
I now used python 3.12.3 and the gdal version is: GDAL 3.7.1, released 2023/07/06 Running this (with UTM coördinates) still only gives night values which all look the same as in my precious message.
This is the metdata I am using. In UTM and SWEREF I only recieved files ending on N. But in Belgian Lambert 72( EPSG:31370) I do recieve files ending on D, but for the daytimes of Africa, because these lat and lon are swapped.
This is strange... Add a POI somewhere so that we can see the actual sun position at every timestep. Also, did you run the SOLWEIG tutorial with Gothenburg data and get correct result?
I've added a POI in the center. POI1.txt file is attached down below.
I did run the SOLWEIG tutorial with Gothenburg data and that gave the correct result.
Very strange. sun positions become nan-values. Must have to do with something concerning the CRS of the DSM since metdata, UTC etc. looks good. Can you try with another CRS?
What CRS would you recommend for data in Belgium, or that should work in general?
I am not sure as I have never seen this nan-values before. It must be related to your original CRS as UTM usually works fine. Maybe you have a geographical coordinate system that does not work well with transformation to UTM. The strange thing is that you seem to get correct coordinates in the RunInfo file when using UTM...
This is the POI when left in Lambert 72. But then the lat and lon are swapped in the RunInfo file.
What proj-version do you have? Go to About in QGIS and find out. Maybe you have an old version.
Here are my settings using a very recent QGIS version (3.42)
In the Qgis I use on the supercomputer i have this (which I use only using python, no GUI).
On my local computer it's this:
No, on my local pc I have just succeeded in receiving correct T_mrt for a the small grid (600x600m) with using the GUI (in Lambert 72). But when doing this on the supercomputer it swaps the lat and lon resulting in wrong D and N times. But my goal is to automate it further in python for bigger grids.
In the meantime I am trying to make this cut fully on the supercomputer. Before i had worked with the files on my local Qgis, so maybe something went wrong because these had different versions. (As in I merged/clipped files on my local Qgis, and then tried to process them om the supercomputer Qgis)
Aha. Then the issue probably lies in that you have multiple installations of gdal etc on you HPC. You need to make sure that the correct version is used. I know that there could be system as well as user installed python versions etc. Personally, I have no idea how to fix this. Please report back when you find a solution. It might be good for other users to see this also.
I have now reran it fully on the HPC, so no cross versions of Qgis were used. But the lat and lon are still swapped. So maybe it is something in that specific version ofQgis/Gdal?
Your swapped lat/lon indicated an old version of gdal. My guess is that you have two conflicting versions on your HPC.
Yes and no. @brdumoul and I were able to do our simulations using a UTM crs, but the issue with the Lambert 72 crs remains. I believe the issue is not caused by conflicting versions of gdal on the HPC. (This was also an issue but has now been resolved).
I plan (when I find the time) to make a minimal reproducible error to see if the issue is caused by this crs.
Maybe you can close this one and I can open a new one once I have the MRE?
Ok, I close. Interested to see the performance of the model on a HPC. When/if you have a publication or report, please share. Good luck with your work!