Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

raster.reconstruct does not work on global netcdfs in 0-360 longitude format #289

Closed
nickywright opened this issue Oct 14, 2024 · 10 comments
Assignees

Comments

@nickywright
Copy link
Collaborator

Reconstructing my raster does not work if my netcdf is in 0-360 format, GPlately will import the raster OK, and say that it has reconstructed it OK, but half the world (the 180-360 portion) will be missing.

I'm guessing this is because static polygons don't align (i.e., are these in -180 to 180 format), because my data ends up with NaNs in it?

i.e.:
Screenshot 2024-10-14 at 3 18 23 pm

checking the longitudes before saving out...

Screenshot 2024-10-14 at 3 18 53 pm
@michaelchin
Copy link
Contributor

michaelchin commented Oct 14, 2024

Thanks @nickywright for reporting this bug,

GPlately should be enhanced to support the netcdf grids in 0-360 longitude format. And when GPlately saves the reconstructed data into a new grid file, the longitude format should be preserved.

@michaelchin
Copy link
Contributor

I will look into this issue after I have updated GWS for FK and made some progress with pyGMT.

@michaelchin
Copy link
Contributor

@nickywright
If it is not too much trouble, could you please send me the netcdf file and jupyter notebook? I would like to do some debugging. Thank you very much. I appreciate your time and effort in supporting GPlately Dev team.

@nickywright
Copy link
Collaborator Author

Hi @michaelchin , notebook is here, and it uses the netcdf file downloadable from zenodo here.

@michaelchin
Copy link
Contributor

Hi @michaelchin , notebook is here, and it uses the netcdf file downloadable from zenodo here.

Thank you very much. I will find some time to look into it asap. I am a bit busy recently. It may take longer than usual. Sorry about that.

@michaelchin michaelchin self-assigned this Oct 23, 2024
@michaelchin
Copy link
Contributor

@nickywright
Found a temporary workaround. Set the "realign=True".

raster = gplately.Raster( data=miocene_file, time=15, plate_reconstruction=r_model, realign=True )

@michaelchin
Copy link
Contributor

@GPlates/gplately-dev

This issue can be fixed by setting the "realign=True". It is False by default. Anyone knows what is the reason that it is False by default? Can I set to True by default?

@jcannon-gplates
Copy link
Contributor

It does sound like internally GPlately/pyGPlates would like to use [-180,180] (instead of [0,360]). So one idea is to realign internally regardless of the realign parameter (to [-180,180]). But respect the realign parameter (eg, go from [-180,180] back to [0,360]) in save_to_netcdf4?

Ah, but Nicky's example is writing with gplately.grids.write_netcdf_grid(..., grid=reconstructed_raster._data, ...). So that idea won't work.

@brmather might have a better idea.

@brmather
Copy link
Collaborator

Hi all,

The most painless way forward is probably to realign to [-180,180] before reconstructing the raster then un-realign it to [0,360] after it has been reconstructed.

@michaelchin
Copy link
Contributor

This bug has been fixed in master branch.

Use this notebook to verify the fix.

Further improvement to the raster reconstruction function will be tracked with #310

Close this one now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

4 participants