Engineering Computational Science

Professor James Hetherington

2026-04-30

Or…

Data &

Computers &

Code &

People

Part one: An exploration of scientific programming

This lecture has three parts. In the first, which has some practical examples, I attempt to explain some important aspects of what it means to program computers for science.

In the second, I look at the philosophy of computer programming for science, and consider its study as a research discipline. This part doesn’t have practical examples and is just thinking.

In the third, I look at some possible futures for this field in the context of the development of deep learning and generative AI, again with some practical examples.

1.1 A young person’s guide to programming gravity

• It’s about 1989
• A BBC Micro starts, “beeep-boop”
• A teenager has been reading about gravity.

Image credit: The National Museum of Computing.

It’s the mid-1980s. A BBC micro starts - Beep Boop!. I’m an early teenager, and I’ve just been reading some stuff about gravity. The explanation sort of makes sense, but I like programming on my new-ish home computer, and I feel like there’s bits of it I haven’t understood.

1.2 - The rules of gravity

• Change your velocity toward anything heavy:
  • The heavier it is → the more you accelerate
    • Twice as heavy → twice as much
    • The further away → the less you accelerate
    • Falls off with the square of the distance
  • “Toward” means a vector:
    • velocity has a speed and a direction
    • the change points toward the heavy thing

It’s the mid-1980s. A BBC micro starts - Beep Boop!. I’m an early teenager, and I’ve just been reading some stuff about gravity. The explanation sort of makes sense, but I like programming on my new-ish home computer, and I feel like there’s bits of it I haven’t understood.

[Picture of BBC micro] [image - a young person’s guide to bbc basic]

I start trying to programme the computer to run a gravity simulation.

So, kid-me has been told the rules of gravity work like this:

• Accelerate - change your velocity - toward anything heavy
  • How much? Well, the heavier it is, the more you change your speed
    • And it’s ‘proportional’ - so twice as heavy means twice as much change
    • And it goes down with how far away from the ‘sun’ you are,
      • proportional to how big the surface of the sphere is between you and the sun (square of radius)
      • (does this mean the gravity is ‘spreading out’ so there’s the same amount over the sphere?!?)
  • What does it mean ‘toward’ anything heavy?
    • Well, it’s a vector - your velocity is a speed in a particular direction
    • And the change is in the direction of the sun or whatever.

How do we make that in code?

We need to start by examining ‘change your velocity’.

We’ll work in 2-d, with x and y coordinates.

Suppose there’s no gravity, and we have some speed, and the current speed is vx metres per second in the x direction, and vy metres per second in the y direction.

1.3 An introduction to pseudocode

Let's have a time step dt, and make it small, so dt = 0.1
Each time step:
    x = x + vx * dt
    y = y + vy * dt
    Draw it
And that's the end of the time step, so go round and do it again.

The code on this slide is not meant to be real, runnable source.

It is pseudocode: code-like text designed to pull out the key idea.

Now, this is supposed to be a public lecture about computer programming. How are we going to do this?

During this lecture, there will be some actual programmable demos I’ve built, but the code on the screen won’t be real code - it’ll be text designed to pull out the key aspects I’m trying to explain, that looks a bit like code. (We call it “pseudocode”). Pay attention to this idea of pseudocode - it’ll be important!

The demos are all generated using real code - and are available online for those who would like to look at them later - not in BBC basic but in Python so there’s some utility for a modern audience.

If we show this animation, we get a dot, moving in a straight line! [Demo]

1.4 Adding gravity

The loop structure is the important thing: we repeat a small update over and over again:

dt = 0.1
loop:
    distance_to_sun = square_root (x^2 + y^2) -- Pythagoras!
    amount_to_accelerate = gravity_strength * sun_mass / distance_to_sun^2
    x_share_of_acceleration = x / distance_to_sun
    y_share_of_acceleration = y / distance_to_sun
    vx = vx + amount_to_accelerate * x_share_of_acceleration
    vy = vy + amount_to_acceerlate * y_share_of_acceleration
    x = x + vx * dt
    y = y + vy * dt
end of loop

In order to type this in, we have to have started developing understandings of scalar and vector quantities, and child-me has made, based on the bit of calculus that he’s starting to know, some kind of guess at how small time steps should enable us to implement velocity as change in position - how many metres do you go in a given amount of time.

Note the “loop”, a bit we do the “each time step” bit over and over again, and we indent to show the bit that’s looped.

Now we can put in a sun at (x=0, y=0), and add gravity:

dt = 0.1
loop:
    distance_to_sun = square_root (x^2 + y^2) -- Pythagoras!
    amount_to_accelerate = gravity_strength_constant * sun_mass / distance_to_sun^2
    x_share_of_acceleration = x / distance_to_sun
    y_share_of_acceleration = y / distance_to_sun
    vx = vx + amount_to_accelerate * x_share_of_acceleration
    vy = vy + amount_to_acceerlate * y_share_of_acceleration
    x = x + vx * dt
    y = y + vy * dt
end of loop

We type this in, and watch the video, and it looks like it’s working! [Demo]

1.5 Pseudocode as an intuition builder

• If I can’t code it, I didn’t really understand it.

Most of that benefit is in pseudocode, not real code.

def acceleration(position):
    r = np.sqrt(position[0]*position[0] + position[1]*position[1])
    G = 100.0  # Gravitational constant
    g = G / (r * r)  # Gravitational acceleration
    return - g * (position / r) # Make it point toward origin

• Pseudocode isn’t enough - we need a working model to be confident there isn’t something we missed
• But the careful thinking isn’t in the language syntax.

The lesson here that I really want to get across here is that for me, and for many of us, the process of building the code, is a really useful way of making sure there’s none of the science you don’t understand. I definitely didn’t understand this properly as a kid, but the point of doing this WASN’T to build a gravity simulation. It was to use the process of programming as a tool to explore whether you’ve really understood the thing you’re trying to put in the computer. We call this “modelling” - the computer contains a ‘model’ of the earth going round the sun. The process of writing the code even pseudocode - especially pseudocode - has really forced us to tighten up our thinking.

We don’t gain that much more tight thinking from the real code than the pseudocode - but there’s a lot more “noise” - this might be the only ACTUAL CODE you see.

Now, let’s think through this a little carefully:

• pseudocode isn’t enough - we need a working model to be confident there isn’t something we missed
• but once we’ve gone through that process and it’s working, the steps of careful thinking, the rigor that the modelling process has forced us to, isn’t in the language syntax
• we’re seeing that the process of coding forces us to build scientific intuition - coding is an ‘intuition pump’.
• but that the power of this really resides in the pseudocode
• a real programme is necessary for verification we’ve done the work, but pseudocode is a sufficient embodiment of the intuition

This will be important.

1.6 Simple isn’t always correct

But then we draw the trajectory over time - and instead of being a circle, it doesn’t quite meet up! Something is wrong! Oh no, did we misunderstand gravity!?!?! [Figure]

Now, probably quite a few of you in this audience will know that the problem here is the approach to implementing the calculus - the small timestep approach we took is called “Forward Euler Integration”, and it works quite badly. After asking some annoying questions, this really blew me away as a kid. We followed the ‘obvious’ approach to implementing the meaning of velocities and accelerations, and it sort of worked, but sort of didn’t. A quick trip to Kendal library and an implementation of Runge-Kutte helped sort that out.

So this is another aspect of our lesson about what we learn by programming in science: effectively implementing computer programmes to model the world introduces us to interesting new challenges, in ways that we didn’t expect.

1.7 - Birds and sheep are particles too

The rules for the Boids:

1. Cohesion – fly toward the centre of the flock.
2. Separation – avoid getting too close to neighbours.
3. Alignment – match velocity with nearby boids.

Another thing tenage me really liked a few years later - I think I saw this in one of my Dad’s books but then did an implentation on Archimedes - is that pretty similar code to this can be used - with a different rule for acceleration - to simulate behaviour of flocking sheep. (Remember I’m from Cumbria.) Or indeed flocking birds - with really beautiful videos.

You can code in rules for formation flying, avoiding predators etc.

The rules for the Boids:

1. Cohesion – fly toward the centre of the flock.
2. Separation – avoid getting too close to neighbours.
3. Alignment – match velocity with nearby boids.

This also really made an impression on me - the kind of understanding-with-rules, where you aren’t properly convinced you’ve understood something until you can get a computer to do it, works in biology and sociology, and history, as well as physics.

1.8 Simulation and Modelling

Modelling allows us to use simple rules to build human understanding of complex systems.

Simulation allows us to build detailed models to predict how the world will behave.

Image credit: Peter Coveney and Roger Highfield.

When we describe the rules of a system and work out the consequences with a computer, we might be doing “the software is expected to precisely describe the real world, to the point where we could use it to build and manage an aircraft” - a simulation or ‘digital twin’ - to “the software is expected to display some interesting characteristics of the real world” - a model. This is not an either-or - there’s a spectrum of options in between.

The more toward the simulation end of things we are, the more the objective is to be able to use it as a tool, but also, the way in which we verify our science is by comparison with experiment.

The more toward the model end of things, the more the learning comes from the process of modelling itself. This helps build our intuition as to how the system works - not simulations.

The approach we’ve been talking about - to describe a system by a set of simple rules - short of the laws of physics or an approximation to more complicated behaviour like flocking sheep - and then understand the resulting behaviour by exploring the modelling process and observing the results of the model - is an important part of the background that got me into this. Ecological systems modelling leading to nice chaotic fractals.

It’s a big part of why I’m into using maths and computers and software to study things outside physics. My Dad bought a copy of a book called ‘frontiers of complexity’ just as I was heading off to uni - I would later have the author of that book as a postdoc supervisor, using computer simulations to model blood flow in the brain. [Wave to Peter.]

1.9 Speed - readability tradeoffs

Some of you will have noticed that the gravity programme is inefficient:

    distance_to_sun = square_root (x^2 + y^2) -- Pythagoras!
    amount_to_accelerate = gravity_strength * sun_mass / distance_to_sun^2

could be:

    amount_to_accelerate = gravity_strength * sun_mass/ (x^2 + y^2)

Some of you will have noticed that the gravity programme is inefficient:

…we’ve saved ourself doing a square root and then a square. Do we want to make that change? The new programme will be faster, but it will be harder to understand. Does that matter? Well, what if we want to change the programme, or give it to someone else to make changes? My grandad was also into this kind of thing, and it was nice to be able to show him the code.

1.10 Performance and complexity

• Speed matters in scientific programming
• It adds to complexity
• It is necessary

Speed really matters for this kind of code. Let’s look at an example: we can plot how long it takes to run our gravity simulation, for various different kinds of tools for doing fast numerical calculations, instead of the simple python code.

We can get a big speed-up from using more sophisticated tools, but there’s LOTS AND LOTS of new complexity. Do we understand how to use these tools? Do we understand the tradeoffs between them? Do we understand the new kinds of bugs they can introduce? Do we understand how to debug them? Do we understand how to test them? Do we understand how to make sure they give the same results as our simplest code?

1.11 Warehouse scale computers as toys and tools

We call these ‘compute clusters’ or ‘supercomputers’ or ‘warehouse scale computers’.

Even getting them built is a serious challenge, there’s physical complexity in things like getting the heat out of the computer - these things now have fluid pipes that run through them - computer blood - for managing heat!

In order to get to this point of working with computers-that-share-the-work, there’s a lot of complexity that needs to be understood. The interesting part for me is that the complexity of how you structure the machine feeds through into the kind of code you have to write, and vice versa.

1.12 The abstraction stack

By working with programs that use other programs that use other programs, we are much more capable.

But the systems become much more complex.

And hard to understand.

It’s a LOT harder to write the program now. And a lot easier to make mistakes. But calculations are possible that would otherwise not be.

Now, you might like it if you could ignore the details of the message passing and all that.

When you’re working in BBC basic - you never need to know about the engineering details of how the memory works.

In computer science we call this an “abstraction stack”

[diagram]

… and whenever the concerns of the layer below leak through into the layer above, we call that an “abstraction failure”. We’re often trying to prevent such failures, by clever forms of ‘encapsulating’ that complexity. But it never fully works - you can only drive down the rate and signficance - and that’s part of why this work is fun and challenging.

This is our second deep lesson: because in science we use computers to understand the world, but the calculations are expensive, and the stack is deep, the trade off between lucidity and speed really matters. (We usually say ‘complexity and performance’.)

1.13 Part one - recap

• Code for understanding, as well as to drive the computer
• Can code for sheep as well as physics
• Models and simulations
• Performance matters for scientific programming
• So abstractions leak

Part two: Reproducibility and Reliability in Computational Science

2.1 - Effective

My PhD work - under Professor Bryan Webber, who is here today - illustrated this instinct that “I don’t understand something properly unless I can automate it as a computer programme”.

There was a particular calculation in theoretical particle physics - which you would do as a combination of mathematical work with pen and paper and a numerical calculation. The end result of which determines whether some candidate theory or other - new particles and suchlike - would be detectable at the then-being-built-LHC.

I wanted to try to write something which generalised this, so you could specify the theory idea and the systematisable parts of the work - the algebra and the numerics and the interaction between them - was done by a computer. Even though there were lots of problems with the result - and the candidate theories never did show up at the LHC - I’m still proud of the principle. We’ll come back to this in a moment.

2.2 The Avoiding Mass Extinctions Engine

• Save the world and make a bob or two doing it.
• Sustainable change.
• Socio-technical solutions.

Image credit: Gavin Starks et al.

Fast forward a few years, to 2009. I’m outside academia for a while, working for a startup doing climate impact modelling - the name of the company was AMEE - the “Avoiding Mass Extinctions Engine”. It’s a for-profit social enterprise - with a mission to save the world, and make a bob or two doing it. [AMEE bug logo] [Climate matrix symbol]

This really suits me politically - I’m uncomfortable not working for mission/purpose - I want my jobs to be ‘for good’, but I also like the sense of building a product, of demonstrating that you’ve got something of real value. This will be important later when we talk about approaches to verifiable understanding.

What our product does is not model the climate - we model polluters. E.g. a computer programme that tells me “if I build a big computer, how much will it harm the climate?” The point here is that Obama was about to pass climate tax legislation, and if that had happened, it would have put such models in the financial-services-business-planning loop.

2.3 Computational science as a political football

Image credit: Generated with the DALL·E image model, OpenAI, accessed via ChatGPT (April 2026).

In 2009, a group of researchers building computer models of climate at UEA were hacked by climate denialists. In addition to taking various email comments out of context to undermine the science, the hackers exploited bug reports in those emails. Issues with developing computer simulations - part of the work I described in the previous section - were played up to undermine trust in climate science.

As a result of this - a manufactured scandal arising from a hostile disinformation campaign - but with a kernal of truth in the need to improve scientific practice when using software as a critical research instrument - investers were no longer willing to invest in “cleantech” for a while - digital startups working on climate adaptation and mitigation - and AMEE failed.

This really struck a chord with me. There were genuine - innocent - mistakes in the model programming. But there were examples of things where a more careful approach to programming would have prevented these. And where science is a political football - being used to make decisions that matter for the future of the world - we need to work very carefully - bend over backward - to be very sure our science - and thus the code that drives it - is correct.

By this time I’d realised that my PhD software was also very buggy and badly engineered I should add. My successor in Prof Webber’s lab had a lot of tidying up to do! (Sorry.)

2.4 The Joint Biosecurity Centre

Image credit: Screenshot from Github.com April 2026.

As another example of the importance of trustworthiness in scientific code, during the covid crisis I was a senior advisor at the Joint Biosecurity Centre, building the team that did the modelling that put together the national R number - remember that?

One of the things that concerned me was that, at the beginning of the crisis, the models that were being used were running in the universities that built them. This was a risk, partly because university systems aren’t designed for the kind of reliability that national crisis resilience requires. But also because of the reputational risk to the university sector of operational decision making being done through codes that were designed for research purposes, often without the kind of robust engineering practices I’ve been working to spread through academia.

I’m proud that I was able to help colleagues navigate the challenge of getting these codes moved to a national shared secure resource, while still benefitting from the understanding developed within the higher education sector.

2.5 Software Engineering

Image credit: Photo by PA Media, purchased for this lecture.

Software systems now govern our lives, and, as a society, in practice we are terrible at it.

However, a large body of practice, around testing, documentation, change management and so on has emerged. Applied carefully, these help make it less likely that our software systems will harm us.

It’s important for practitioners to know and follow these codes when building code that “matters”. I’m a Fellow of The British Computer Society - the UK’s professional institute for information technolgy.

As with other areas of engineering, these include both the highly technical and things that are more like management science, and the interaction between them. For example, “agile project management” techniques grew up within software engineering.

2.6 What is engineering?

The tools, practices and systems that enable repeatable, reliable, safe and scalable technical construction.

There is a name for the methods humans have come up with to allow us to build things reliably: Engineering.

There are lots of different definitions of engineering around, but one I favour runs something like:

the tools, practices and systems that enable repeatable, reliable, safe and scalable technical construction

It’s about how we come up with ways to, given our flawed human natures, make things that don’t break all the time!

As scientists, we are concerned with understanding the world.

As engineers, we are concerned not just with wisely using our understanding to make changes to the world that are beneficial, but building ways of working that sustain and protect those benefits.

[Illustration - earthquake]

2.7 Not just software engineering

Image credit: The Alan Turing Institute.

Now, software is not the only aspect of computational science - we’ve talked about the hardware and network engineering of warehouse-scale computers.

Computational statistics - these days we call it “data science” - is another aspect of computing with an evolved, but patchily applied system of professional practice. As computing has evolved, the statistical profession and the computer programming profession have experienced a complex interplay, with rules of practice evolving in response.

The BCS and the Royal Statistical society work together to build professional practices for data science.

The data itself, is also a key part of this - librarianship is a long-standing professional practice, and the new profession of data stewardship is emerging - a computational librarian of data.

All of these are just as critical to effective computational science and are in scope of the emerging discipline we’re trying to describe here.

A key part of any engineering practice is a sustained ethical framework, and mechanisms for professional practice that ensure that these ethics are upheld.

I would like to imagine that you haven’t reached real professional status as an engineer until you’ve refused to build something in ways that violate these codes.

I won’t go into details in public, but as a data scientist working in the covid response in the UK government, I have achieved this.

2.8 Science and Engineering

In the previous section, we talked about professional engineering. I gave examples of long standing and emerging professions in computing - information technology. These professions exist outside the scientific context - in software and data companies selling cars and T-shirts, in news websites and in the civil service.

I want to dig for a moment into the relationship of science and engineering, touching on four aspects of the relationship.

People often think about the question of science-for-engineering: using an understanding of the world, built up from the tools of science, to build useful things to help us manage and control the world.

We’ve seen examples of this already with climate modelling and covid modelling. It’s actually a moderately controversial point as to whether science is that important for engineering. A lot of technologies have been built by trial and error without understanding the science behind them.

Personally, in my work I’m primarily motivated by computational science for science - understanding the world - rather than computational science as a means to technology.

We’ve seen that in the model-simulation continuum, simulation is of primary utility for engineering, while modelling is of primary utility for science, though this is not clear cut.

You’ll see that my forays into application are usually driven by a sense of accountability - where the technologies that are related to the science have risks or benefits that matter enough to the world that we have a duty as scientists to be concerned with them.

It’s also the case that advances in scientific understanding are often driven by engineering goals. Our Boids example - the flocking behaviour - was motivated first by the need to make things that look like flocks of birds, for special effects in movies, and then only later applied to animal behaviour as a science!

This is also highly motivating - the role of the application is not only to deliver a technology, but to act as a driver of science. This is a highly signficant feedback loop, and a major part of the real story of how science proceeds.

There’s a different flavour of science-for-engineering. Not the use of understanding that emerged from science to help with engineering challenges, but rather, the application of the scientific method to discover which tools, practices and systems of engineering, are effective. We can use rigorous methods to investigate questions of which kind of CAD tool is best for building cars, or which structure of an engineering company delivers most reliably. We’ll extensively discuss such approaches in a moment.

While all four of these touch my research practice, the fourth category is the one I’m most interested in: the application of engineering to the tools of science? Sometimes this is called “instrument science”: how best do we build a telescope? A supercollider?

In the first part of the lecture, I tried to convince you that scientific simulation codes, and the computers they run on, are one such interesting engineering challenge in science. How best do we write trustworthy computer code to be applied as part of the scientific endeavour, and how do we design that alongside the computers it will run on? (We call this “co-design” of software and hardware.)

2.9 The Research Engineer

Image credit: Beineke Library, used by permission, composed by the Software Sustainability Institute.

Since the climate crisis events at AMEE, I began, with others to think about what kind of intervention might help the reliability and trustworthiness of computational science.

We hypothesised that a professional community of engineers would be necessary for efficient, productive and trustworthy research, given the accelerating importance of computing in science.

There are now thousands of people around the world employed as part of this set of professions I helped to invent, and a formal scholarly society for research software engineering.

I lead a team of a bit less than 150 at UCL, in the UCL Advanced Research Computing Centre.

Probably a lot of the reason I’m standing here is the success of this idea - we’ll talk more in a moment about whether that’s a scientific achievement or not.

Considered thus, engineering is part of management science, and a social science.

Sometimes it helps to know some science - but what engineering adds is this layer of tools and approaches, and these are designed in the context of human behaviour and human motivations.

I think this is part of what I bring to my role as co-pro-vice-provost of UCL’s Grand Challenge of Data Empowered Societies.

I’m not a social scientist, but as a practicing engineering leader, I’ve played a significant role in building the social systems that control engineering in computational research. I’ve been at the sharp end of these issues, and hope that that practical knowledge can help with the challenge of making the role of data and computers and software in society safe.

2.10 Definition

Engineering Computational Science is the development and application of tools, practices and systems for the efficient, trustworthy, ethical and safe use of information technologies as part of trying to produce knowledge about the world.

So now we’re ready to define what I’m interested in - what I claim to be a professor of!

Science is the use of systematic methods to avoid lying to ourselves when trying to understand the world - more on this in a moment.

(When I say the world I mean the human and built worlds as well as the natural world - economics counts.)

Computational science is doing science using information technologies - software, computers and data - as a primary research instrument.

Engineering is the development of tools, practices and systems for the efficient, trustworthy, ethical and safe generation and maintainance of technologies. Computer engineering is the development and application of those tools and practics to information technology.

Engineering Computational Science is, therefore, the development and application of tools, practices and systems for the efficient, trustworthy, ethical and safe use of information technologies as part of trying to understand the world.

So now you know what I do.

Science and scholarship are more interesting than most other things people do… (I would be happy to be into programming for the arts or sport, but not selling widgets…), and you get to study those things when trying to make software about them, including some quite hard maths, which I like, given my background in theoretical physics.

But there’s a more interesting reason than that: Research IT has additional measures of value which have to be optimised for besides performance (running fast) and maintainability. The usual reason programmers try to write lucid code is given as maintainability - code which is hard to understand is hard to look after, update and catch bugs in. That’s certainly true.

But in research, the code is not just a “thing to get a computer to do what you want”. It is itself an accurate description of the algorithm you’re carrying out - often the only accurate one - and as such a key part of the scientific process - reproducibility. It’s also a key part of understanding a system - the modelling-as-part-of-securing-your-understanding concept I began the lecture with.

They’re also a vital part of teaching about it - well written software has pedagogical value.

And they play a role in the politicised aspects of computational science that I’ve referred to - transparency, but also, interestingly, openness to public engagement and widening access to participation in the research process.

It’s these additional aspects of the duties of IT when it forms part of a research process that makes it interesting to me. Research instruments are never purely tools, they are always bound up in the study, enfolded within the knowledge production process. Thus the engineering of research instruments - from telescopes to sequencing machines to supercomputers - is a particularly interesting engineering-science problem.

2.11 Epistemic cultures

Image credit: Generated with the DALL·E image model, OpenAI, accessed via ChatGPT (April 2026).

We need to think for a moment about how we might study this field.

I remember vividly arriving at university and having my naive, untroubled view of science as a formal, clean way of building understanding of the world absolutely demolished. (This is one of the reasons why it’s important to have inter-academic-cultural dialogue across student populations.) I think (except among fundamentalist or propaganda groups who have never practiced in a university), it is quite generally accepted that science is a messy, complex social process.

I do believe - and I think there’s ample evidence - that whatever science is, however it works, does work well to help us build understanding. But it’s not at all like the simplistic hypothesis-test-theory charicature. We’ve already seen one example of the richer and more complicated nature of how science moves forward by considering engineering-for-science, science-for-engineering, and engineering science.

For me, there are many different tricks to how we avoid lying to ourselves. Sociologists of science call these ‘epistemic cultures’.

Anyone who is using any of these careful practices to avoid self-deception can reasonably be said, I think, to be doing science. (Some would prefer scholarship, or another term, that’s fine, my only beef is with epistemic exclusionists.)

Over-obsession with a particular epistemology - theory of knowledge - way of building truth, is naive “scientism” - science as a fundamentalist religion, not as science.

The randomised clinical trial is by far from the only valid research methodology. Don’t get me wrong, I love RCTs, and there are colleagues who are making great progress by finding new ways to apply them outside medicine.

But there are rigorous research disciplines that reason from observation, without experiment - like some parts of astronomy.

There are cultures that learn through deep engagement with small sources - close reading in the humanities for example, or rigourous qualitative research in the social sciences or economics through interview-based methodologies.

There are whole sub-fields of physics that primarily develop through mathematical reasoning and only occasional access to new data, but make progress from a focus on parsimonious explanation - elegant theories evolving from a heuristic of mathematical beauty. We could spend ages talking about Science vs Wissenschaft.

Complexity science - exploring the world by writing down rules and exploring their consequences computationally - is another such important epistemology. Hugely scientific, but because we don’t evaluate on the basis of formal comparison with experiment, but by drawing conclusions based on evaluation of the feel of elegance and explanatory power - not a match to the classical “scientific” charicature. The emergence of computer simulation, the other part of the third paradigm, alongside experimentation and elegance-seeking mathematical reasoning, is another.

My view is that our work of knowledge production is constantly developing new tools, all of which, so long as they are based on some kind of approach to self-deception-limiting, are valid parts of scientific inquiry.

As we discover new research disciplines, we therefore need to ask, what will be effective self-deception-limiting ways of working, appropriate to the challenges of that domain.

One powerful approach, but one I do not make use of in my own work - not because I don’t believe in it, but just because it doesn’t suit my temperament - is the empirical software engineering approach. I need to explain it carefully now, by way of explaining what my wonderful colleagues who work in this way do, so that I can explain how my approaches differ.

In this approach, scholars engage in systematic studies of large bodies of software engineering work - and contrast the effectiveness of various engineering methodologies. One can, for example, look across all the open source code in the world, compare different testing practices, and see which result in higher bug generation rates. This is a well-established approach, and produces interesting and useful results.

One can also deliberately make interventions - such as give a subset of projects free access to some research software engineers - and observe the results, approximating a controlled trial. Again, fascinating, but not my thing.

The primary methodology applied within the computational science cultures I grew up in - theoretical physics, high performance computing, and computational biology - is what I call the Tinkerer’s Epistemology. One observes a challenge, develops a hypothesis for a software tool, or more commonly, a modification to an existing software tool, which would make it work better, (produce results faster or more accurately).

With existing tools, this approach can often have the nice property of being self-verifying: one can immediately see whether a change makes a positive impact to a metric such as simulation result time, and include the graph in a publication. This is highly emotionally satisfying, but as we shall see it also has important properties when we consider the future of the domain, as we shall see in the third part of the lecture.

Now, many code changes can have multiple effects on different metrics - reducing lucidity (and thus maintainability, trustworthiness or pedagogical value) - while improving performance. And such additional concerns are not self-verifying. Thus the tinkerer’s epistemology - “What Works?” - is flawed when we consider these aspects.

2.12 The reproducibility crisis

Science is the formalisation of ways to avoid lying to ourselves

• Reproducibility is a key part of how science views itself.
• This ideal is far from realised
• We should be able to do well in computational science.

Given the complexity of the task of effectively using computers in research, it is no wonder we run into these challenges.

We’ve just seen examples of where science reaches out from the task of understanding the world to become important in looking after the world, and thus the importance of computational reliability.

But problems with reliability in computationally driven science don’t just undermine the correctness of our practical advice or public trust. They undermine the goal of science - to find ways to approach true understandings of the world.

Science, in it’s self-conception, views reproducibility - the idea that a paper should enable another scientist to run the same study and verify the conclusion - as an important part of why the so-called scientific method works.

There’s growing evidence that across many disciplines this ideal is far from realised.

One might hope that in computational science, where a program constitutes a formal, unambiguous script which describes the model and how it was used, reproducibility would be higher. In fact there reasonable arguments that it’s no better, and perhaps worse. [https://pmc.ncbi.nlm.nih.gov/articles/PMC8530091/?utm_source=chatgpt.com]

If you work in computational science you’ll have come across loads of these. Genes being automatically renamed by excel to months because they both have three letter codes is one popular example. I’ve seen - no names today to protect the guilty - published content in a nature paper that was based on numbers where two very large numbers were subtracted from each other - what we call in the trade a ‘floating point underflow’ - essentially random. It was not retracted.

So we have learned: we need to build our computer systems for science carefully, to ensure our science is trustworthy.

In computational science, we have developed practices to enable our workflows to be fully automatically reproducible.

For example, this lecture is a computer programme to generate it. If I make any changes to the exemplar simulation code or text, the simulations will all run on UCL HPC clusters, and the website you’re viewing it on will automatically update. It is not a powerpoint.

2.13 Service provision as an academic practice

• Utility
• Curiosity
• Community

I can therefore now turn to why, in 2012, when working on the brain bloodflow codes, I formed the research software group in UCL as part of what many would frame as “IT support”, of all things.

I was feeling that I needed a bit more verifiable utility and impact in work on computational science tools, and needed the rigor that customers bring to the evidence basis.

Now, there’s a lot wrong with service culture when applied to the research process - because, as I have argued, the tools are part of the research process, they can’t be safely externalised - outsourced - from the scientific endeavour.

But there’s a lot of value in market data in evidencing the value of contributions to the research process - and potential that this works for the non-self-verifying aspects of cultural and management interventions - such as developing the role of the research software engineer. The market success of the research software engineer intervention, therefore, becomes part of the evidence basis for the correctness of this conjecture.

I’m by no means the first to take this step in combining instrument science with service provision as a research methodology. Some labs - constructed as labs, within the research culture - such as the Diamond Light Source, or the European Molecular Biology Laboratory - have been doing it for years.

However, there’s been a challenge in doing this in the context of software-as-a-research-instrument. There’s been an evolution in universities for core IT - the IT that manages the payroll and does the email - to move away from the academic functions of the university and be established as a professional service. This is for good reasons - there’s no particular reason for these to be part of the academic culture, unlike for research instruments.

What we’ve been able to establish in UCL ARC is, therefore, particularly exciting, in that we’re both a research lab investigating - through the service provider’s and tinkerer’s epistemologies - how best to use data and computers and software as research instruments, and as a reliable professional service with real market data. I think there’s more we can learn about services close to a university’s academic mission in other areas besides IT from the success of UCL ARC.

It’s been a challenging journey to establish the research-IT-as-academic-and-professional identity in the institutions I’ve worked for.

It’s pushed against the grain of separation of the academic and professional cultures.

It’s also pushed against the trends of academia itself - epistemic diversity requires recognition of new forms of research output - the tinkerer’s github pull request, the practicing engineers’ architectural standards document, a management policy document on professional models for staff scientists - as valid research outputs alongside traditional research papers. Colleagues, such as Simon Hettrick’s “Hidden REF” work have been critical.

One of the things I’m proud of about working for University College London is that it’s been challenging the rules of academia since it’s foundation - admitting women and religious nonconformists for example - and I’m pleased that my appointment as professor recognises that the approaches to scholarship that I’ve championed are fully valued at the third best university in Europe. (According to one fairly spurious benchmark.)

Part three: Some futures

3.1 Physics-free gravity

My tagline - data and computers and code and people - centres data. But we’ve not really talked about data yet. I want now to turn to the recent past and the future of engineering computational science.

The biggest change during my career - only hinted at when I first started the research software group at UCL in 2012 - has been the emergence of the “big data” approach to computational science.

It’s time to turn to a demonstration again, to explain what this is about.

Let’s take our gravity code, and run it lots and lots of times - we’re pretending to build up a big dataset of observations, which might have been measured by Tycho Brahe with a telescope.

Now, instead of writing down the laws of physics, let’s put in a model that doesn’t know anything about gravity - just a big old mess of rules that might get you from one frame to the next - and get a computer to find the values of the unknown numbers in that model that make it fit that data (parameters).

This used to be just not practical. It turns out that with a particular configuration of computer hardware that was invented for doing graphics - graphics processing units or GPUs - this became managable from around the mid-2010s. These days we can do it fairly quickly.

3.2 The triumph of stamp collecting.

Image credit: Wikimedia commons, Heptagon, CC-SA.

“All science is either physics or stamp collecting” - attributed to Ernest Rutherford, perhaps apocryphal.

This is really interesting.

“All science is either physics or stamp collecting” is a dismissive gag attributed to various famous historical physicicists. Well, we might not like it, but it turns out the stamp collecting won.

This approach - building a model that correctly predicts system behaviour from data alone, without a rules-based understanding, has been the main story of science and engineering for the last ten years.

It gets called the fourth paradigm.

It turns out that disciplines that do a really good job of managing and organising and labelling their data - data librarianship - have a real advantage in exploiting it. We often hear that google deep mind solved the protein folding problem with alpha fold. And it’s certainly not the case that getting the curve-fitting to work was easy. But in my view, the real credit goes to the people who did the data stewardship that made it possible - that curated millions of protein shapes and sequences over years.

This field - designing storage formats for scientific data, working out what data to keep, what to throw away, etc, is called research data stewardship. The data about the data is called “metadata”. It’s grown in importance throughout my career.

Some of the engineering challenges faced by data stewards can be quite fun - such as losing data during a pandemic at a critical moment due to a hard limit on the number of lines in an out of date version of Excel being used in the NHS. Hint - excel is not a sensible scientific file format for good data stewardship.

This approach has been hugely powerful in science-for-engineering : if we build models that accurately predict how the universe will behave, that’s very useful for things like - in the case of protein folding - making drugs.

But somehow, for me, it misses part of the point of science: we didn’t get into this to help do useful things. We got into it to understand the world, and helping do useful things is a really great side effect.

It’s also sometimes the case that not using understanding-of-the-world makes these models a bit fragile. When colleagues built an epidemiology-free data model of covid, it worked really well until the virus evolved a new variant.

There’s a lot to be investigated here - with my PhD student Lewis O’Donnell we’re exploring how much physics - perhaps zero - we need to put into a model of fusion reactors to reliably help colleagues at the atomic energy authority.

3.3 FAIR and Open science

• Findable
• Accessible
• Interoperable
• Reusable

One significant part of the cultural change that is being driven by the adoption of this research approach is the growing distance from data collection to data exploitation. This is another aspect of the growth of instrument science - automation in data gathering - but also in research IT in data storage and management. And the ability of data to be shared from the group that created it to groups that can use it challenges systems of scientific credit and the metrics that are used to measure researcher value.

This idea - open reuse of data - and the code that helps us analyse it - is referenced as open science. It has many benefits, as well as challenges and cultural risks.

We now talk about FAIR data:

• Findable
• Accessible
• Interoperable and
• Reusable

as a better and more careful response to the needs of the fourth paradigm. This also goes to addressing the reproducibility challenge.

3.4 Five Safes

• Safe Data
• Safe People
• Safe Projects
• Safe Settings
• Safe Outputs

In the context of an insecure world, where research can be used for harm as well as help, there are security risks too - as my old supervisor Professor Finkelstein who will give the vote of thanks has explored.

(With my PhD student Mahmoud Abdelrazek we’re about to start a new project exploring the risks of bad actors poisoning our digital twins.)

3.5 Models as data

Image credit: Finkelstein, Hetherington, Li, Margoninsky, Saffrey, Seymour and Warner, IEEE Computer.

Image credit: The Mathworks, Inc..

I first started working in formal data management as part of my first postdoc. This was my first foray outside physics - looking at using maths and computers and data to understand diabetes. I was lucky enough to have a brilliant cross-disciplinary UCL supervisory team - Anthony Finkelstein, who will do the vote of thanks today, as my computer science supervisor, and Rob Seymour, a brilliant complexity scientist as my mathematical modelling supervisor, and Anne Warner - one of the founders of computational biology at UCL, and a leading physiologist, as my biology supervisor.

Anne and Rob are sadly no longer with us, but I do want to acknowledge strongly their influence on me as an interdisciplinary computational scientist. I think the vision for the challenge I’m trying to set out today began because of the influence of that boundary-breaking UCL team.

Now, what was the data that we were building management tools - ontologies - for? This is where things get interesting, because the datasets in question weren’t just numbers, but models!

A computer program:

def acceleration(position):
    r = np.sqrt(position[0]*position[0] + position[1]*position[1])
    G = 100.0  # Gravitational constant
    g = G / (r * r)  # Gravitational acceleration
    return - g * (position / r) # Make it point toward origin

or a description of a scientific theory:

“Planets orbit as ellipses, with the sun at one focus”

is just data. It’s a bunch of letters and words.

There’s a lot of beautiful computer science theory about how models and data are interplay - you can even show that every mathematical proof is a datatype.

If we’re careful with our data stewardship - keep the right metadata - we can apply big data methods to the models.

We can apply the fourth paradigm to the language - whether computer language or human - itself.

3.6 Living with Machines

Image credit: Living With Machines project, Alan Turing Institute and British Library.

I’ve always loved linguistics. As a kid I borrowed one by one every “teach yourself language” book in Kendal library, not to learn the languages, but to read about how all the different grammars work.

It makes me sad, in the same way understanding-free fourth paradigm science always makes us a little sad, that the engineering challenge of translation was solved by big data methods, not chomskian approaches.

But at the same time, the fact that language itself has now come within the domain of engineering computational science gives us so many opportunities. In one project, where we’re modelling healthcare workers giving each other antibiotic resistant disease moving around the hospital, language modelling makes it practical to use nurses’s notes as a dataset to help us fit the model.

At the Turing Institute, I was able to work with a brilliant interdisciplinary team of historians and social scientists to study industrial accidents in the industrial revolution, using all the British Library’s books and newspapers from the 19th century - all of them! History at scale.

This is one of the things that taught me the importance of epistemic pluralism. Bringing new areas into computational research, and then working out how to engage carefully, respectful of varied epistemic cultures, across disciplines, is really interesting and requires a humble approach. There’s too much ‘takeover’ from tech in much of digital humanities and colleagues and I have tried to take a different path.

3.7 Research software engineering and LLM coding

Now, you’ll all by now have heard about LLMs and software engineering, and all the programmers losing their jobs, and thinking that all of this sounds completely moot - we had a good run with the research software engineers, but now we’re all about to get replaced by AIs.

The truth is much more interesting, and is going to be, I think, an area where getting it right, will be a fascinating research area for the rest of my career, and one where the service-provider epistemology is key.

I’m going to be working out the future role for research technology professionals in interdisciplinary scientific teams - using LLMs for science carefully, maximising the degree of AI automation in the discovery process - while tracking reproducibility and the need for F.A.I.R. approaches carefully.

There’s going to be lots to explore in how we do this well, fairly and in a way that builds trustworthy scientific cultures. But there’s one thought I want to leave us with.

It’s always been part of the goal of computer science to minimise the distance between our careful description of the algorithm and the computer representation. Code like our python examples is translated into machine code by a compiler. No one (actually, some do) bewails the fact that we no longer toggle our computer programmes into the computer using binary switches. (Punch cards were a fad.)

I began this talk with pseudocode - natural language carefully representing the steps we want to take. It’s reasoning these steps out, that has always been the point of the software engineer, not the syntax of the particular language.

3.8 Mathematical assertions as AI specs and automated tests

In the limit that the timestep is small, and the floating point precision is high:
      orbits should be ellipses with the sun at one focus, 
      with orbital periods squared proportional to major axis cubed

def Converges (F : ℕ → ℕ → Set State) (L : Set State) : Prop :=
  Tendsto (fun q : ℕ × ℕ => F q.1 q.2) (atTop.prod atTop) (𝓝 L)

theorem kepler
    (P : Params) (x0 : State) :
    ∃ L : Set State,
      Converges (solveOrbit P x0) L ∧
      IsEllipse P L ∧
      (period L) ^ 2 = ((4 * Real.pi ^ 2) / P.μ) * (semiMajorAxis L ^ 3) := by
  sorry

Image credit: Lean Focused Research Organization (FRO).

With my PhD student Thomas Ghorbanian starting in September we’re going to be looking at how we might be able to know LLM-generated scientific software is reliable.

Research software engineers have always been trying to reduce the distance from the maths to the computer representation - to make it as lucid as possible. While I was at the Mathworks I worked on how we represent models as diagrams, and automatically translate these into code, for just this reason.

The fact that an LLM can take my pseudocode, and generate the python is just the latest in this chain.

What this does to the economics of being a professional research engineer, and how UCL ARC responds, I look forward to finding out.

Part four - endmatter

4.1 Recap

• We’ve understood what research engineering is from code examples
• We’ve defined it as a discipline
• We’ve considered it in relation to science and engineering and its links to both
• We’ve considered methods of knowledge production and concluded that academic service provision is an important part of scholarly practice.
• We’ve looked at some futures: data-driven science, security and federation, and AI-assisted engineering

4.2 Thanks (part one)

All those who have mentored and helped me in each of my prior roles

• Chris, Alan, Ben and Bryan for the PhD
• Anne, Rob, Anthony, Peter and Ofer for the beacon project
• Kris, Malcolm and Gavin at the Mathworks
• James, Jen, Andrew and Gavin at AMEE
• Peter, Derek, Rupert, Miguel, Dave and Owain at the CCS

4.3 Thanks (part two)

• Claire, Bruno, Owain, Jonathan, Mayeul, Jens, David, Raquel and many others from RITS
• James, Martin, Christine, Jon, Alan, and many others at the Turing
• Bryony and Mark at UKRI
• Clare and various nameless folk at the Joint Biosecurity Centre

4.4 Thanks (part three)

All those who have helped me over the last five years in UCL, including but not limited to:

• Donna, Jonathan, Ben, James, Jenya, Owain, Emma, Tim, Rachel, Susan and many others in ARC
• Andy, Ben, James, Paul, Sarah, Jo, Ric, Tom, Alan, Lloyd, Sandra, Fiona, Caroline, Maysaa, Sophie
• Geraint, Claire, Aimee, Paul (RIP), David, Steve, Danny and many more across UCL
• Allison, Katherine, Max, Martin, Katie, Lynn, James, Francisco, Sam and the grand challenges team

4.4 Thanks (part four)

Colleagues from across the research engineering community

• Neil, Simon and the gang at the SSI
• Rob, Mark, Sadaf, Simon, Paul, Jeremy, Mark, and many others in related roles across the UK
• Greg and successors at the Carpentries
• The RSE Association and all its leaders over the years
• Sandra, Dan, Michelle, and others across the international community

4.5 Thanks (part five)

• Sue
• Lindsay
• Bob, James, Clare, Lorna, Chris, Julian, Caroline, Steve, Khadija, Jan, Salley, Jim, Katherine, Kath, Matt, Phil, Alex, Graham, James, Dave and others for silly games and silly conversations.

4.6 Background for the questions