Month: April 2018
Crowd-solving problems in earth science research
This year’s EGU featured a new and interesting event format: SC1.29/GM12.1 Crowd-solving problems in earth science research organized by the early-career geomorphologists Anne Voigtländer, Anna Schoch, Elisa Giaccone, Harry Sanders, Richard Mason and Johannes Buckel. I was among the lucky participants.
In their blog post, the organizers summarize the event and highlight its role in stimulating active participation and communication. When I was a young PhD, active participation and communication was something I missed at these large conferences. Rather, I found myself consuming talks rather than being an active part of the discussion. After a few years I now feel more at ease, I actively contribute, and the EGU assembly has become a place to meet colleages and friends.
I think that an event format like the crowd-sourcing session could stimulate this process in particular for young researchers. This doesn’t mean, however, that — if the session was happening next year — only young researchers should attend. Rather, this event would benefit a lot from the exchange of the young and experienced scientists. I’ll definitely take part next year, and I hope you’ll do so, too.
Increasing speed in MATLAB 2018a
Today, I finally installed MATLAB 2018a. As always, I am quite excited about the software releases shipped every 6 months. One of the release notes on performance particularly caught my interest.
Loops that contain mainly indexing and scalar math operations execute faster due to execution engine optimizations. (see here)
TopoToolbox contains a number of tight loops with scalar math and thus I expect that this release should make TopoToolbox generally faster. I tested this using the function flowacc with a large DEM (SRTM-3, 90 m resolution, about 239 Millionen pixels). flowacc has been coded to be fast and thus there is also a C-coded MEX-file available for benchmarking. However, the code can also be run as pure MATLAB code which I have done in 2017b and 2018a. I measured run-times with tic-toc using 20 repetitions. The results are shown below.
M-code in 2018a takes about 77% of the time required in 2017b. That is a major improvement. Moreover, run-times are close to the C-code benchmark (118%). Can it get much better than this?
Now let’s put this in relation to other software. What we have looked at are flow accumulation run-times for the entire Himalayan range at a resolution of 90 m. 4-6 seconds is quite fast, I guess. In ArcGIS, the same operation would take hours*. But I am a bit reluctant to test this in detail.
*Note that ArcGIS doesn’t keep data in the main memory. Thus, much of the time may be used to swap data between the main memory and the hard drive. A direct comparison is thus not fair.
TopoToolbox 