[GPlates-discuss] Large rasters in GPlates 1.3 and GPML
john.cannon at sydney.edu.au
Wed Nov 13 12:35:43 AEDT 2013
Thank you for the details - this is very helpful.
I'll send you an FTP voucher to upload those files (if you could include the plates Shapefile with the raster that would be great - I suspect the cause of the slowdown is more related to the Shapefile).
The log message "Unable to mesh polygon: bad allocation" (in your log file) happens when we use CGAL to refine a delaunay triangulation of a plate polygon (to generate a spherical mesh for it), and it looks like it ran out of memory (and moved onto the next polygon). The difference here between GPlates 1.3 and previous versions is 1.3 supports self-intersecting polygons using CGAL's exact predicates. Whereas previous GPlates versions would reject a self-intersecting polygon which would then appear as a hole in the reconstructed raster (and the message "PolygonMesh::initialise: Unable to mesh polygon - it's self-intersecting." would appear in the log file).
> but when one connects to the polys to reconstruct, that slows down a lot initially
Yes, each time one connects a raster to the polys (to reconstruct the raster) the above meshing code runs over each polygon and that is generally the cause of the slowdown (even in 1.1.1 and 1.2 there's a noticeable few seconds where GPlates is unresponsive while it's busy doing this meshing). But it seems like the meshing is taking a lot longer with 1.3.
> All I can think is that there is something with the cache file reading?
If it's the cache file reading then, for the most part, the slowdown will happen before the raster appears on the screen (ie, before you're even able to connect the raster to the polys).
But that can't be tested when reloading a recent session - can only be tested when manually loading raster/poly files and then manually connecting them.
But I would definitely like to test this out to confirm whether it's the cause or not.
Also if you could say which build of GPlates 1.3 you use (eg, Windows or Mac 32-bit or Mac 64-bit, etc) because different builds are compiled with different versions of the CGAL library - it may be that we need to build with a more recent version for that platform for example.
From: gplates-discuss-bounces at mailman.sydney.edu.au [gplates-discuss-bounces at mailman.sydney.edu.au] on behalf of Lester Anderson [arctica1963 at gmail.com]
Sent: Wednesday, 13 November 2013 1:02 AM
To: GPlates general discussion mailing list
Subject: Re: [GPlates-discuss] Large rasters in GPlates 1.3 and GPML
The raster does eventually work and the connection to the shapefile activating, it just seems to take a rather long time when reloading a recent session with the raster, rotation and plates layers.
The fact it loads fairly quick on 1.1.1 and 1.2 would suggest to me it is not the raster, but something else inside 1.3. Is there a ftp site I can upload the file to for you to check?
Once the layers are all up, then everything works fine and I can spin the globe quick with the raster cookie-cut to the plates. All I can think is that there is something with the cache file reading?
The time consuming issue is not importing the raster, but when one connects to the polys to reconstruct, that slows down a lot initially.
GPlates 1.3 only crashes if I try to manually close it while doing its slow bit (looks unresponsive).
With everything up and running the log window shows:
Logging to console started at Tue 12. Nov 13:34:20 2013 by GPlates 14188
******Start testing python capability******
python import test passed.
python math test passed.
python system test passed.
******End of testing python capability******
[Warning] PolygonMesh::initialise: Unable to mesh polygon: bad allocation .
I do think that complex plate polygons (no coastlines) can be a problem, as when there are overlapping nodes and ring geometries (from ArcGIS); I currently edit things with QGIS.
On 12 November 2013 00:31, John Cannon <john.cannon at sydney.edu.au<mailto:john.cannon at sydney.edu.au>> wrote:
Thanks for reporting the problem.
Can you upload (or tell me where to get) that 65Mb raster ?
I'd like to try to reproduce the problem - it sounds like an issue in 1.3 since the same raster loads fine in 1.1.1 and 1.2.
Also I'm interested if Sabin's suggestion of deleting the '.cache' files and re-importing helped.
And if you've got a crash log I can look at that would be great.
And which GPlates 1.3 build were you using (eg, 32-bit or 64-bit Mac, etc) ?
And whether you used the same computer to load that 65Mb raster for 1.1.1, 1.2 and 1.3 (this helps determine if it's a graphics hardware specific issue) ?
From: gplates-discuss-bounces at mailman.sydney.edu.au<mailto:gplates-discuss-bounces at mailman.sydney.edu.au> [gplates-discuss-bounces at mailman.sydney.edu.au<mailto:gplates-discuss-bounces at mailman.sydney.edu.au>] on behalf of Sabin Zahirovic [sabin.zahirovic at sydney.edu.au<mailto:sabin.zahirovic at sydney.edu.au>]
Sent: Monday, 11 November 2013 9:40 PM
To: GPlates general discussion mailing list; GPlates general discussion mailing list
Subject: Re: [GPlates-discuss] Large rasters in GPlates 1.3 and GPML
I am unaware if the raster file size limit has been imposed. Today I loaded up a ~900 Mb netcdf grid of gravity anomalies into GPlates 1.3 and it worked fine. Could it be the memory limitations, or perhaps the graphics card having issues? I would try first deleting the existing GPlates cache files for this raster, and then re-import that raster using GPlates 1.3. If that does not work, perhaps you can send the crash log to one of the programmers. If at all possible, uploading the raster file itself would help reproduce the problem. But try the initial suggestions first.
The GPMLZ file is a compressed version of the GPML, so you are likely just seeing a whole bunch of hexadecimal code. To get the readable GPML, open the GPMLZ in GPlates, and save it out as a GPML using Manage Feature Collections > Save As > Select GPML and you should be fine.
Hope that helps!
MR SABIN ZAHIROVIC | PhD Candidate
School of Geosciences | Faculty of Science
THE UNIVERSITY OF SYDNEY
Rm 414, Madsen Building F09 | The University of Sydney | NSW | 2006
M +61 416 775 589<tel:%2B61%20416%20775%20589>
E sabin.zahirovic at sydney.edu.au<mailto:sabin.zahirovic at sydney.edu.au> | W http://www.earthbyte.org<http://www.earthbyte.org/>
This email plus any attachments to it are confidential. Any unauthorised use is strictly prohibited. If you receive this email in error, please delete it and any attachments.
From: Lester Anderson <arctica1963 at gmail.com<mailto:arctica1963 at gmail.com>>
Reply-To: GPlates general discussion mailing list <gplates-discuss at mailman.sydney.edu.au<mailto:gplates-discuss at mailman.sydney.edu.au>>
Date: Monday, 11 November 2013 9:35 pm
To: GPlates general discussion mailing list <gplates-discuss at mail.usyd.edu.au<mailto:gplates-discuss at mail.usyd.edu.au>>
Subject: [GPlates-discuss] Large rasters in GPlates 1.3 and GPML
I have a large raster file (~65 Mb) which will load and run fine in 1.1.1 and 1.2, but with 1.3 it will crash the program. Is there an upper limit on raster sizes that can be used?
Secondly, the GPML format has changed to a format that can no longer be read in an editor (it is a binary file) as GPMLZ - has the whole thing been reorganized?
It is no longer possible to check the GPML file for errors as before.
GPlates-discuss mailing list
GPlates-discuss at mailman.sydney.edu.au<mailto:GPlates-discuss at mailman.sydney.edu.au>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GPlates-discuss