Last week

AMD vs LIFE itself

The main distraction last week arose from generating some extra biodiversity results for Margaux. We’d spotted the previous week that there were some rounding errors, which were evident because the trash scenario whereby land is just removed should never have a positive impact on biodiversity, but we found that in some cases we’d get a really small positive impact, that was suspiciously at the value of half the floating point epsilon value for the CPU.

I dug into this more, and figured out that it related to the used of the power function in numpy, whereby if we did the same calculation in a numpy array versus using numpy scalar values we got a different answer, and then when we subtract those two numbers, rather than get zero we get the rounding error. Obviously this error is small, but we then sum all the species together, which takes this error from being insignificant to possibly significant (and certainly way over epsilon).

>>> x = 0.8706432910332182
>>> import numpy as np
>>> y = np.array([0.8706432910332182])
>>> y** 0.25
array([0.96596205])
>>> (y** 0.25)[0]
0.9659620498640555
>>> x ** 0.25
0.9659620498640554

I was chatting to Patrick about this, and he pointed out that this test case didn’t have rounding errors when he ran it on different machine, and so I ran it on every other computer I had to hand, and it turned out it was only the one particular computer I was using that saw the weird results - but unfortunately for us it was the same machine on which we had run all of the data for both Margaux and the LIFE paper.

I did find a work around, which was to use numpy.float_power rather than the ** operator or numpy.power, so at this stage I filed an issue with numpy and set about re-running both the trash data for Margaux and the restore scenario for the LIFE paper, as my concern here was what impact this might have on the results for the LIFE paper results - it’d be very embarrassing to have to go to the team and explain all of this.

The numpy team were super responsive and helpful, and we eventually traced it down to a difference between how the SIMD operations on the latest AMD EPYC CPUs performs compared to the regular floating point operations. Unfortunately, this kind of rounding error is one that the numpy team have chosen to allow: floating point numbers are only an approximation anyway, and the rounding error here is so small it’s below the usual threshold at which differences are deemed significant. This is unfortunate for us, because it means we need to be very careful using numpy on machines and we probably need to start adding some tests for machines before we do big runs that things behave as we expect. With the LIFE metric it’s not clear how to weed out these errors - it’s clear if you’re looking at things that should be zero but aren’t, but in most cases we’re not dealing with zero values, yet we still have this rounding error that will accumulate as we sum all the species layers. For now we can use float_power or we can force all scalar math into arrays of one element to ensure they get the same treatment, but it’s all too easy to forget/miss that this has to happen.

Thankfully, after much number crunching and trying to learn how to run R scripts, I was able to reproduce the last output of the LIFE pipeline for the restore scenario with Z=0.25, and the results whilst slightly different at the 10^-14 range, and not significantly different, and as Tom points out the errors are less significant than other sources of uncertainty in the pipeline, such as the accuracy of the range data from IUCN.

In all this we did also update Daintree’s firmware to see if AMD had made any tweaks to address this, but alas it did not, but I’m still grateful to Malcolm for his help on ruling that out.

Tropical Moist Forest Evaluation Methodology Implementation

I did some minor changes to the TMFEM documentation, and I have some small tweaks left. At the project meeting at the end of the week we agreed that baring a couple of minor changes, we were happy to publish the 2.0 methodology in the coming week.

Orlando chat

I had an interesting discussion with Orland Timmerman, a student on the AI4ER CDT. He’s looking at impact of interventions on coral reefs, and is using a mix of traditional raster processing and machine learning - it seems like a nice mix of the kind of work we do on the LIFE and TMFEMI pipelines and the more ML centric methodologies other EEG group members are using. I gave him some limited pointers of how we deal with some of the scaling issues he’s hitting, pointed him at Amelia as he was interested in Apache Sedona, and hope to keep tabs on what he’s doing, as in future this pipeline might be useful for evaluating shark like things in as it’s close to what we already have in our test cases, but does step over into the ML side of things.

Data sharing

This is done at last! I published the bulk data I had to share with our remote collaborators via the lab’s website in a crude-but-gets-the-job-done manner. I still think longer term we want a better solution, but for now this is good enough.

A Climate Unconference

I went to an Unconference organised as a response to COP28 by Alex Deschamps-Sonsino, who runs the Low Carbon Design Institute. It was held at the new UCL campus down at the old olympic park in Stratford.

It was a small turn out, of about a dozen or so people, but it was highly interesting as a result, with a day full of genuine discussion on a wide range of topics around different concerns and actions around climate change. Laura James (first EEG speaker of next term!) has done a great write up, so I’ll not duplicate that, you should read that instead, but as a taster, we had discussion on:

• Do we need more data? The building we were in has lots of telemetry, but getting any change to how the building operates to reduce its carbon footprint based on that data doesn’t seem to be possible. The olympic park is covered in bat monitoring sensors and has years of historic data, but they can’t find anyone interested in consuming it.
• How do you link those doing the big analysis of environments using satellite data, machine learning etc., with the ground practitioners who actually would benefit from it.
• How does the use of “risk” and “fear” help in delivering messages around impact, particularly at the local authority level, where the speaker had been working with authorities that will have negative impact from flooding in the east of England, but were struggling to get people to engage with that.
• How do we engage people in the discussion of “away” as a concept - your rubbish goes “away”, your resources come from “away”, how do you get people to think about circular economies.
• What is the role of “violence” in climate action (which mostly does mean property damage rather than against humans), and how have authorities shifted the discussion around protest to make it harder to not be arrested for any non-trivial expression.
• How to engage a next generation in repair, and move it from being seen as the domain of certain niches of society.

There was only small amounts of overlap in the audience experiences, so that really helped make for people paying attention and contributing to the group discussions.

For my part, given there was some design talent in the room, I did a take on the undone science work, but this time trying to flag this as an area where interaction designers could really make an impact if we could find a way to include them. The chat linked nicely with the “is there too much data” discussion that happened in the previous session around trying to affect change at UCL with how buildings are run based on telemetry, where ultimately the conclusion was that there was no one in the organisation who’s job it is to do that, so the problem isn’t data, rather one of politics, it could perhaps be seen in our work that linking comp sci to ecology is a bit of an after thought to some degree, and so similarly getting design into the question is not one of “how can designers help” but first “how can we get people to want to get help”.

All in all, an interesting and thought provoking day, and I do recommend you read Laura’s notes. It’d be interesting to think about how we’d assemble such a diverse set of voices to have a similar discussion in Cambridge.

This coming week

• Final changes to TMFEM v 2.0.
• Look at Google colab docker image for Andrés, as he could not get it to build locally
• More work on pyshark, as the spelunking I did and all the data churn I went through would have been so much easier with that.
• Document all the machines - we have quite a few now
• Try again to tidy up the LIFE pipeline code for both publication and getting a single common codebase for use with the IUCN