The Archieve of FILTRATION LINEAR CURVE

At RWTH’s HackMining hackathon, I worked on an ANDRITZ challenge to analyse filtration curves, identify their linear region, and calculate the slope and intercept associated with cake and cloth resistance. The aim was to make the analysis fast and reproducible, so we had a clear technical problem to work on.

What caught my attention was how easy it would be to organise the entire project around producing those two numbers. That was the most clearly defined part of the brief, and it would be straightforward to demonstrate that the software returned them. But I kept coming back to the person receiving the result: what would they need to know before deciding it was good enough to use?

When someone asks for a calculation, I want to understand the decision waiting on the other side of it, because that can change what I need to build. If they are responsible for accepting an analysis, giving them an answer without enough information to assess it may simply move the difficult part of their work somewhere else.

For this challenge, I wanted someone to be able to see which part of the curve had produced the result. Placing the selected interval and fitted line on the original curve would let them inspect the selection directly. Otherwise, I would be asking them to trust a choice the software had made while giving them very little basis for questioning it.

An automated calculation might take seconds, but if someone then has to reopen the data and reconstruct the analysis to feel comfortable using it, the time saved becomes less convincing. That is why I would look at the effort required to reach an accepted result, including any checking or correction, rather than treating calculation speed as the whole improvement.

I also find that imagining an awkward case helps me understand the design more clearly than imagining a successful one. What if two parts of the curve appear suitable? What if none does? A screen that always presents a confident-looking answer would be easy to design, but I would want to know how the person doing this work would handle that ambiguity before deciding how the software should behave.

Their answer could change the scope quite substantially. They might need to review a suggested region, or they might need the tool to stop and explain why it cannot produce a dependable result. I wouldn’t want to choose between those behaviours based on which made the demonstration smoother, because each gives the person a different degree of responsibility and control.

The optional scale integration and container-change detection in the brief also made me look further back in the process, towards the experiment producing the measurements. They raised the question of what context should remain attached to the data so that a result could still be understood later. I saw those requirements as clues about the work surrounding the calculation, with their importance still needing to be established.

During a hackathon, that wider view can easily turn into too much scope, so I wanted a clear reason for anything added to the design. Showing the selected region had a direct purpose as it would help someone examine the result. Other additions would need to earn their place in the same way.

What I enjoy bringing to this kind of project is the ability to question a requirement closely enough to make it more useful to build. I want to understand where someone needs help before deciding what the software should take over, and what they will still need to judge for themselves. With the filtration challenge, that meant following the calculation beyond the moment the numbers appeared on screen, into the work of deciding whether to use them.