A New Era in LC Troubleshooting Tools

The integration of artificial intelligence (AI) and large language models (LLMs) has nearly completely removed what used to be a significant coding barrier that stood between analytical chemists and applications useful for liquid chromatography (LC) troubleshooting. In this article, I demonstrate how an LLM can be used to quickly prototype apps that are useful for troubleshooting, using the commonly encountered problem of higher-than-expected pressure in an LC system. Within a few hours, a reasonably polished version of a simple web app can be built and checked for accuracy before implementation in the laboratory. This new capability should open the door to a proliferation of tools for use by the analytical community.

In early September, I attended the 35^th International Symposium on Chromatography (better known as “ISC”; https://www.isc2026.org/) in Prague, Czech Republic. Unlike the HPLC meeting series, which is held every year and rotates among North America, Europe, and Asia, ISC is held in even-numbered years on the European continent. ISC 2028 will be held in Spain, and ISC 2030 will be held in Denmark. I was generally impressed by the high technical level of the oral presentations and posters that presented new research developments across all areas of chromatography, sample preparation, and data analysis. There was a very strong showing from young scientists attending as students and postdocs in both the oral and poster programs. After four days packed with technical sessions, panel discussions, and social events, I returned home both with a lot of research ideas to pursue and completely exhausted from a highly stimulating week.

One of the more interesting parts of the conference was a panel discussion on AI in separation science, which was moderated by Bob Pirok from the University of Amsterdam. The panelists included John McLean (Vanderbilt University), Christian Huber (University of Salzburg), Leon Niezen (Vrije Universiteit Brussel), and me. About 60 conference attendees joined the discussion, which lasted for about 90 minutes. We covered quite a bit of territory, with topics including the use of AI tools in data analysis and method development, building databases that can be used for model training, increasing “smartness” of analytical instrumentation, the use of AI in publishing science (both by authors and reviewers), and, of course, the question of whether or not AI will replace “us” (the analytical chemists) any time soon. In some of these areas, there were diverse opinions among panelists and audience participants. However, I would say there was a strong consensus on one particular aspect that stuck with me—that the LLMs from the major vendors in this space (for example, OpenAI, Google, and Anthropic) have become so good at coding that developing simple but useful applications has suddenly become very accessible. A recent example from my own group is the development of a simple, web-based interface for analyzing chromatograms to get retention times and peak areas (https://homepages.gac.edu/~dstoll/GustieChrom.html). In other words, the “coding barrier” used to be high enough that most analytical scientists would not bother trying to build applications or programs for use in the analytical space, even if they had a good idea for one. Most of us didn’t have enough coding skills to do it. We had to have a friend or coworker, or hire someone with the coding skills to build the program or application we had in mind. Now, it is clear that this coding barrier has been obliterated. Given a good idea, any of the frontier LLMs can help us build an app that brings that idea to life in a few hours. Several of the panelists and audience participants at ISC reported that this type of AI-assisted app development is becoming more common in their research groups. My experience has been that it usually takes longer to validate the accuracy of the application than it does for the LLM to build the app. In the past month or so I’ve been receiving emails from commercial organizations offering to build apps with names such as “Flow Split Designer” and “Active Solvent Modulation Sizer.” It appears that a person or a bot has read my publications and realized they contain ideas that could be turned into useful apps. And so, I think we’ve entered a new era of LC troubleshooting, where we will see a proliferation of apps built using at least a strong assist from AI tools that improve the quality and efficiency of our troubleshooting experiences. To me, this is a very exciting development, and in this installment of “LC Troubleshooting,” I will demonstrate the development of an app for troubleshooting pressure problems in LC systems to show what is possible.

Any App Starts with an Idea for a Tool That Would be Useful

One of the topics I’ve written about in this column as much as any other is the pressure problems we encounter in LC. Although pressure problems can appear in many forms and for many reasons, the one we deal with most often in my laboratory is pressure that is too high, due to a partial blockage somewhere in the system. And it’s the “somewhere” part that can be frustrating, because it is not immediately obvious where the blockage lies. Together with Jim Grinias, I wrote two articles suggesting that we treat our LC systems like circuits and apply ideas from electronics and circuit analysis to find out which element in our LC system is producing the higher-than-expected pressure.^1,2 A central idea in this troubleshooting approach is that we know, somehow, what the expected pressure drops over different elements of the flow path are, so that we can detect when a pressure drop we observe is outside of the normal range. This knowledge of what to expect can come from personal experience or calculations based on theory. However, while the calculations are not hard, per se, finding the equations that are needed and the relevant physical constants to use takes some time, and when we are in the middle of a troubleshooting exercise, we usually don’t have a lot of time to spare to build up a spreadsheet from scratch, for example. So, why not leverage the remarkable coding abilities of LLMs to build an app that leverages the best available theory and knowledge to form a solid foundation for how it works? And even better would be to have this app run in a web browser so I can share it with friends and colleagues, and perhaps even use it on my phone while standing in front of the instrument.

How Quickly We Get to a Useful Prototype Depends on the Quality of the Prompt We Give the LLM

Over the past couple of years, we’ve heard a lot about the importance of good prompting in getting LLMs to do good work for us. The more specific we are in our prompt, the more likely the LLM will actually do the work needed to solve our problem, whether that is building a grocery list for a new recipe I want to try or writing a Python script to sort data files. Following is the prompt I put together for building our “LC Pressure Troubleshooter”:

Prompt: “Please build an app for me that will run in any web browser (both desktop and phone apps) for the purpose of troubleshooting pressure problems in liquid chromatography systems. I am open to suggestions for improvement, but I suggest you build an interface that enables the user to indicate all the elements in the flow path of their LC system between the pressure sensor in the pump and the system outlet (i.e., atmospheric pressure). I suggest you start with five elements by default and allow the user to choose the type of element from a dropdown menu that includes: 1) tubing, and 2) filter. If the user chooses tubing, allow them to enter the length of tubing (in mm), and choose from a dropdown menu that includes diameters of 1) 0.002” (50 micron); 2) 0.003” (75 micron); 3) 0.005” (120 micron); 4) 0.007” (170 micron); and 5) 0.010” (250 micron). Allow the user to easily remove elements that are not needed. Then, enable the user to indicate the mobile phase composition they are using by entering the type of organic solvent (choices include ACN and MeOH), the percentage of organic solvent in the mobile phase, and the flow rate (in microliters/minute). Then, for each element in the flow path, calculate the expected pressure drop across the element using Poiseuille’s law, and viscosity estimated from the dataset published by Billen et al. (I’ve uploaded the relevant Billen paper here for your reference). Next, calculate the cumulative pressure drop that will be measured by the pump as each element in the flow path is added, starting at the pump and adding elements in the downstream direction. Finally, provide input boxes where the user can enter the pressure values they measure, starting with the complete flow path, and removing one element at a time. And then, add a big button labeled “Troubleshoot” that the user can press after they’ve entered all their measured pressure values. When the user presses this button, calculate the experimentally determined pressure drop across each element of the flow path, and compare these values to the expected values. Finally, prepare a message to the user indicating which flow elements are likely leading to the higher-than-expected pressure they are trying to troubleshoot. The strategy employed here follows two articles also attached here entitled “Treat it Like a Circuit.” When building the app, use a color scheme that relies on the following main colors: FFCF00, 005695. Build a prototype of the app in the sandbox on the right of this screen so that we can iterate on it quickly before deploying it. Add an “About” tab that describes the functionality of the app and how it works. Indicate that it was developed by Dr. Dwight R. Stoll at Gustavus Adolphus College and build a changelog with version numbers to keep track of the evolution of the app over time.”

Although I requested several aesthetic changes to produce the app shown in the next section, the prompt above was sufficient to produce the baseline version of the app in one shot.

The LC Pressure Troubleshooter

A screenshot of the app running in a web browser on a desktop PC is shown in Figure 1. The code was developed using Google’s Gemini LLM and can be accessed for free at https://homepages.gac.edu/~dstoll/lc_pressure_troubleshooter/lc_pressure_troubleshooter.html. The app also renders nicely on mobile devices.

I think the layout is pretty intuitive, but it works like this. First, we enter the organic component of the mobile phase and the percentage of organic solvent in the liquid, as well as the flow rate. The app then estimates the viscosity of the liquid at 25 °C, which is relevant to most troubleshooting exercises. Then, we specify how many elements there are in the flow path between the pressure sensor located in the pump and the fluid outlet to the atmosphere. By default, the app loads five elements, but we can remove extra ones or add more if we need them. For tubing elements, we can indicate their lengths and diameters, and the app calculates the expected pressure drop across each element using Poiseuille’s law. For filter elements, the app assumes a pressure drop of 5 bar, but since this will be filter-specific, we have the opportunity to enter our own value, if we happen to know it better.

Once we have built the model of the LC flow path, then the troubleshooting can really begin. The app instructs us to first record the pressure indicated by the pump with the entire flow path intact and enter it in the top box on the right-hand side. Then, we remove one element at a time from the downstream end of the flow path and input the observed pressure each time we remove an element. Once they have all been recorded, we press the “Troubleshoot” button. At this point, the app compares the expected pressure drops for each element shown on the left-hand side of the screen to the actual pressure drops calculated from the measured values entered on the right-hand side. Finally, a message is displayed at the bottom of the screen for each element, indicating whether the element is OK or likely occluded. At this point the user can decide whether to replace or repair the element. As I have written many times in this column, my experience has been that backflushing these elements to solve problems with occlusion usually only provides temporary relief, if any. In my laboratory we usually simply replace the filter or tubing in question.

Performance Validation Is Critical

Over the past several months, students in my research group and I have been building a number of apps like this for internal use, and my experience has been that validating the accuracy of the app generally takes a lot longer than building the app itself. This is probably not new to real software developers, but as amateurs effectively getting into software development, this is something we need to anticipate and be very aware of. In this case, I have compared the estimated viscosities and pressure drops against our HPLC Simulator and Dispersion Calculator, which have been previously verified for accuracy. In the context of this Pressure Troubleshooter, neither of these values needs to be particularly accurate to make the judgment call about which element in the flow path is the problem, so this application is more forgiving than other applications might be.

Summary

In this installment of “LC Troubleshooting,” I have demonstrated how frontier LLM tools, such as Google’s Gemini, can be used to rapidly prototype web-based applications for LC troubleshooting. For this demonstration, I have used the frequently encountered problem of higher-than-expected pressure as an example of a problem that could benefit from a simple web application to accelerate the troubleshooting process. Current LLMs are so good at coding that they have dramatically reduced what used to be a formidable barrier to developing such apps. In this way, building these apps has been democratized, such that anyone with a good idea for a tool can put together something useful in an afternoon, provided they have a solid understanding of the theoretical basis of the tool; this foundational understanding is critical when validating the resulting app for accuracy. I’m very interested to see what the chromatography community develops to expand our digital toolbox. If you build something you are willing to share with the community, please let me know, and I may have the opportunity to highlight it in this column!

References

1. Stoll, D. R.; Grinias, J. P. Treat It Like a Circuit, Part I: Comparison of Concepts from Electronics to Flow in LC Systems, LCGC Int. 2024, 1 (4), 6–10. DOI: 10.56530/lcgc.int.ol2372p5

2. Stoll, D. R.; Grinias, J. P. Treat It Like a Circuit, Part II: Applications and Troubleshooting, LCGC Int. 2024, 1 (5), 6–12. DOI: 10.56530/lcgc.int.wy6073a3

3. Billen, J.; Broeckhoven, K.; Liekens, A. et al. Influence of Pressure and Temperature on the Physico-chemical Properties of Mobile Phase Mixtures Commonly Used in High-performance Liquid Chromatography. J. Chromatogr. A 2008, 1210, 30–44. DOI: 10.1016/j.chroma.2008.09.056.