Remapped sources shapefile intersection distortion around 60-degree North

[zktesemma]

I tried to remap the RDRS 2.1 forcing over the whole Canada and transboundary basin (USA part) for vector MESH. It worked well over most of the area except around 60 degrees North parallel where the remapped sources shapefile showed distorted intersection that created a strip along near 60 degrees North parallel. I am wondering if such an issue was raised in the past if it is not new and any help is appreciated.

Sample for both regular and distorted intersection.

1. Distorted remapped
   

2. Regular remapped
   

[kasra-keshavarz]

Thanks Zelalem, I'll have a look into this.

[ShervanGharari]

Thank you, Zelalem.
Could you please confirm the version of easymore you're using, along with all the packages and dependencies? I believe I’ve encountered this issue before, which was caused by mismatched libraries and environments, leading to problems with the geopandas intersection. Once those were aligned, the problem was resolved.
My second thought which is stronger here, given that it’s above 60 degrees, is that there’s an issue with RDRS where the dataset shows a discontinuity in longitude when the data crosses -180. EasyMore cannot handle this scenario because the grids that jump from -180 to 180 stretch across the domain, which likely explains the issue above 60 degrees. In version 2 of EasyMore, this discontinuity results in an error and needs to be addressed externally. However, datatool can resolve this problem in the dataset, allowing EasyMore to function as expected. Alternatively, you could limit your dataset's domain to values above -180. We have a solution for this that will be included in the next version.
Hope this is resolved as soon as possible.

[zktesemma]

Thank you Shervan, I am using easymore cli of the model agnostic framework: EASYMORE version 2.0.0. I installed all package as per (https://github.com/kasra-keshavarz/community-modelling-workflow-training/blob/main/0-prerequisites/requirements.txt). My study domain covers between -170 to -40 degree longitude so the second may not be the case here. Thanks.

[ShervanGharari]

Thank you, Zelalem. By "domain," I was referring to the spatial extent of the source NetCDF files you're using. Have they been subsetted to a range like -175 to -35, for example?

[zktesemma]

Yes I used the datatool to subset the sources NetCDF before running EASYMORE. Thanks!

[ShervanGharari]

Thank you Zelalem. To investigate further, you might want to try this environment (which is slightly different from the one you shared). This could help identify whether the issue is possibly related to the libraries. Additionally, please check the source shapefile that easymore generated alongside the intersection. This can be done for easymore either from Wheelhouse or directly from GitHub. Just comment out one of the pip install lines for easymore to select the desired option.
I’ll also take a look at it later today or within the next few days. If you can place a sample of the source NetCDF file in a public location on Graham, I can give it a try as well. Thank you very much.

# go to home and remove all the modules and deactivate potential active 
cd
module reset
module purge
deactivate

# load needed modules
module load StdEnv/2020 gcc/9.3.0 openmpi/4.0.3
module load gdal/3.5.1 libspatialindex/1.8.5
module load python/3.8.10 scipy-stack/2022a mpi4py/3.0.3

# remove existing virtual env folder and set up virtual env for easymore
rm -rf ~/easymore-env
virtualenv ~/easymore-env
source ~/easymore-env/bin/activate
pip install --no-index --upgrade pip
pip install --no-index easymore # version 1.0.0 from ComputeCanada wheelhouse
#pip install git+https://github.com/ShervanGharari/EASYMORE.git # version 2.0.0 from GitHub

# run the easymore_code.py
cd to/where/your/code/is/located
python easymore_code.py

[zktesemma]

Thanks, I copied the sample in Model_Output/cache2018.

[ShervanGharari]

Hi Zelalem,
This is my initial reaction after reviewing the NetCDF file you shared. I noticed that there are longitude values lower than -180 in the lon variable. It might help to ensure that the domain is subsetted so that the lowest longitude is -179, with no values below -180.
I believe I’ve identified the source of the issue—it stems from the equal-area projection. The values below -180 are initially projected to meters, but when they’re reprojected back to degrees, they end up near +179 instead of staying below -180. This causes the source shapefile grids in those regions to stretch across the entire globe (from left to right), which disrupts the rest of the calculations, including intersections.
Please try adjusting the domain (while keeping it reasonably close to your modeling domain) and test if the code works properly. Let me know how it goes, and thank you. I’ll also take a deeper look to address this issue in the next version. Thanks again, and I look forward to hearing if the adjusted domain resolves the problem.