How Mathematics Helped Survive the 90s

In 1994, when the whole country was going to pieces and the parliament stood charred after being shelled by tanks, I decided for some reason to quit trading and enroll at Bauman Moscow State Technical University (BMSTU) at the department of "Nuclear Reactors and Power Plants" in the Faculty of Power Engineering.

Maybe it was because I spent my childhood near the Smolensk Nuclear Power Plant and picked up radioactive emissions from the Soviet RBMK-1000 reactor. Or maybe because in my teenage years, having been expelled from 8th grade for antisocial behavior, I enrolled in the Bryansk Machine-Building Technical School. One of my professors there bragged about having applied to Baumanka — he didn't manage to get in, but he considered the mere attempt a great achievement. Apparently, this made an indelible impression on the unformed brain of a 15-year-old nerd. And when I earned some money from the wild trading of the USSR collapse era, I decided I had to study at Baumanka and become an engineer.

In those hungry times at the university, everyone survived however they could. The university paid practically nothing. Some quit teaching and went to work — those who were lucky worked in their specialty or close to it; the unlucky ones worked wherever they could. One of our professors moonlighted as a sales representative and offered me, as a capable and promising nuclear engineering student, to deliver cookies and wafers to stores. But by that time I was already a former store owner, and I didn't want to deal with that nonsense. I wanted to be a physicist or at least an engineer.

The choice of side jobs for underclassmen in the 90s was limited: sports, trading, crime — all without leaving the walls of the university. Picture this: nighttime at the BMSTU sports complex, long trucks loaded with alcohol pulling into the back yard, where future designers of rockets and nuclear technology unload crates of vodka, beer, and gin and carry them into the basement of the sports complex. There, future weapons designers paste bootleg excise stamps onto alcohol bottles with BF glue. On one hand, sports and alcohol don't mix; on the other, loading and unloading alcohol was a perfectly good substitute for fitness and paid pretty well too.

The Birth of PK MVTU

At this time, a wonderful associate professor named Oleg Stepanovich Kozlov worked at the department, teaching us a subject called "Control in Technical Systems." And for some reason he suddenly decided that one should earn money not through trading, but through software development. The department dealt with nuclear reactors and trained hardware designers. Even back then, there were trendy youth-oriented IT departments. But nuclear and energy specialists were considered "shit and steam" specialists and had nothing to do with programming or IT. But Oleg Stepanovich didn't care — for additional income, he began developing a new program for dynamic simulation of technical systems. This was still the Soviet school of mathematics.

Leonid Markovich Skvortsov participated in the work — a mathematician by God's grace who developed his own original methods for solving differential equations for stiff systems. As an author of mathematical methods, he is widely known in narrow circles around the world. A simple search by his name suffices: for example, in a 2025 report on innovative methods for calculating stiff problems, there's a reference to his 2010 work, where he's noted as the founder of one of the two main methods for solving the stability problem for stiff systems.

The Wild 90s

The wild 90s. At this time, the world was painfully transitioning from DOS to Windows 3.11, and deep within Microsoft, Windows 95 was already being prepared — after which all subsequent generations of PC users would forget the command line like a bad dream.

In these legendary times, the majority in the shell-shocked country was trying to survive somehow, while the minority was trying to squeeze or even grab something for themselves. A group of engineer-mathematicians, like the last samurai of Soviet education, continued doing what they had to do, come what may. Like the last legionnaires of an empire, they fulfilled their teaching duty. But to put food on the table, they simultaneously, in their free time from their main work, created a new software product.

A software package for solving simulation problems in control systems with a wildly fashionable graphical interface for the time.

The product's name was as patriotically authentic as could be: Software Complex "Simulation in Technical Devices" (PK MVTU). A reference to the old name of Baumanka — "Moscow Higher Technical School" (MVTU). In those legendary times, absolutely all professors and staff at Baumanka considered the rector an extremist for changing the proud name "Moscow Higher Technical School" to the ordinary, gray, and dreary "Moscow State Technical University." Bauman School was the only one in the entire USSR, while after the collapse, universities multiplied like fleas on a stray dog. Any former fence-building technical school in any backwater proudly started calling itself a university. Baumanka people had their own pride — they looked down on the bourgeois, all believing that the word "school" should be preserved in the name. Although now, I think the rector was actually right back then. Those idiots who came to power after the USSR's collapse could easily have confused the Higher Technical School with some vocational school and shut it down. And the buildings — a former palace from Catherine's era and a Stalinist tower — they would've handed over for a trendy casino-hotel with blackjack and hookers.

Testing by Fire — Student Labs

Thanks to Oleg Stepanovich's iron will, the first version of PK MVTU on 286 computers under Windows 3.1 was deployed immediately into the educational process. Every year, three groups of department students — about 60 people — dutifully spent the academic year going to the lab, sitting at computers, and "using PK MVTU." Students, like mice, cried and pricked themselves but continued eating the cactus — completing lab assignments in UTS on buggy computers running buggy Windows 3.1 in the buggy PK MVTU version 1.0. And I was among those students. There was no greater joy for us young idiots than finding a bug in PK MVTU so that Oleg Stepanovich would come over and say: "Holy crap, look at how the girls are dancing!" That meant that in the evening there would be a showdown in the development team and someone would get it. Later, when I became a developer on that team, they beat me — for my bugs that surfaced when stupid, clumsy students tried to use my magical components in their labs.

As a result of such brutal testing, the software quality became so high in the shortest time that 25 years later, in one of the design bureaus, a sprightly old man grabbed me by the tie in a hallway and said: "Now PK MVTU 3 — that was a great product, written by real engineers, but your crappy SimInTech is written by some half-baked hacks."

Giving Away the Product for Free

Having obtained an excellent product for solving educational problems in automatic control theory and beyond, the authors tried to sell it to universities, but alas — universities had no money back then, so they had to give it away for free. And since everything worked stably and excellently, to this day PK MVTU holds the record in the former USSR for the number of published university methodological materials. Even independent authors at various universities published books about MVTU. And even now, searching for PK MVTU returns a whole list of lab assignments from different authors in different corners of the former USSR.

The Western Software Invasion

After 1998, Western software producers started coming to the country for money. First, the global conspiracy in the person of Bill Gates and Microsoft trained users to pay for software not at the flea market, but through official channels. They used the stick of SWAT raids and the carrot of kickbacks that could be written off as expenses in Western companies' accounting. Then the engineering software producers came, and a bloody bath began.

It was like a horde of nomads attacking peaceful farmers. Western companies bought up engineers in droves for their sales teams, just as Genghis Khan's Mongols drove conquered peoples into their battle formations. Boeing bought Russian engineers from the collapsed aviation industry for pennies and sat them down to the monkey work of redrawing paper blueprints in CATIA CAD.

Western software producers opened offices in Russia staffed by conquered natives exchanging license files for hard currency. Since the conquerors gave distributor discounts to the natives, crowds of people stormed their offices to participate in the plundering of territories.

I myself participated in this celebration of life, selling the French CAD system CATIA.

Saved by Chernobyl

PK MVTU as a product probably would have also sunk into oblivion, like many other products. Especially since back in 1994, when developers at BMSTU were just starting to build MVTU, Mathworks had already rolled out its add-on to MATLAB — Simulink. This very Simulink would steamroll Russian universities within 10 years and get nearly all control theory professors hooked on Simulink diagrams, like the British got the Chinese hooked on opium in the 19th century.

But fortune favored them through misfortune. What saved the PK MVTU developers was that back in 1986, the Soviet RBMK reactor at Chernobyl couldn't withstand the tests that curious Soviet scientists subjected it to, and it exploded. After that, all requirements for designed reactors added a mandatory section — an in-depth safety report requiring mathematical simulation of processes, without which a project couldn't be approved. Like it or not, the answer to the regulators' question "Will it blow up?" now required mathematical proof in the form of calculations using a mathematical model. That's how nuclear reactor designers got accustomed to conducting process simulations.

The RBMK Digital Twin

And it so happened that the general designer of the RBMK reactor — the Scientific Research and Design Institute of Energy Technologies (NIKIET) — was the base institute for the department where the esteemed Oleg Stepanovich Kozlov tormented students with "Control in Technical Systems" in lectures and PK MVTU in labs. As was customary at the time, the design institute brought the department in on projects. One such project was the modernization of the RBMK reactor control system. By this time, the Soviet analog control system for nuclear plants had already become obsolete and needed to be replaced with a digital one, but everyone was terrified — this was RBMK after all.

That's when things started going well for the PK MVTU developers. A real, large-scale task appeared for a real nuclear industry facility. Why large? Because unlike an airplane, car, tank, or even a ship, a nuclear power plant has no restrictions on equipment mass or electrical power. Designers and planners of NPPs can install as many sensors in the control and safety system as they want. As many as the designer needs, plus double (redundancy) and a bit more! Then double and triple everything again for safety requirements. Three-channel safety system, they call it. As a result, the control and safety system turned into an insane monster with thousands of diagram pages, which is difficult not just to mathematically simulate but simply to comprehend for a single person.

Interestingly, in the first nuclear reactor, the safety system consisted of an absorber rod hanging on a rope above the active zone, and an axe lying nearby. You had to chop the rope with the axe for an emergency rod drop and reactor shutdown. Granted, this was an American reactor. In a Soviet reactor, that axe would have been stolen before the end of the first shift. That's why Soviet reactors had automation from the very start: first analog, then digital as computers appeared.

And so at NIKIET, the task appeared to replace the analog Safety Control System (USBT) for the RBMK reactor with a digital one. And before replacing it, they needed to test it on a model; not only was this an IAEA requirement, but it was simply scary. As experienced engineers and programmers say: "If it works — don't touch it." But there was no choice — the service life of the ferrite core memory had expired, it had to be touched.

You could, of course, take Matlab Simulink — it already existed, and some young idiots (myself included) had even learned to use it for UTS in universities. By then, Simulink was spreading through Russian higher education like a cancer in a healthy body. But the problem was that in 1998 it couldn't handle models as large as the RBMK control system. Creating a reactor automation model in Simulink for testing the control system was simply impossible. What to do, boss? All is lost!

And here, on a white horse — Oleg Stepanovich Kozlov, leading a gang of engineer-mathematicians, with PK MVTU at the ready:

"Don't panic, bring us the damn USBT! We'll model it from every angle, like a dog with a chew toy, along with the reactor and turbine as a bonus."

And what do you think? Indeed! A task beyond the capabilities of American MATLAB Simulink at the time was easily and effortlessly handled by the Software Complex "Simulation in Technical Devices" (PK MVTU). Created in spare time by a team led by a professor of control in technical systems. Not for nothing had stupid students tortured it on 286 processors for 5 years.

As they write in advertisements: to solve your complex system mathematical simulation problem, take a simple Soviet... school of mathematics. Thus PK MVTU, together with simulation capabilities, was integrated into the design process for RBMK control systems and, moreover, created what we wouldn't be afraid to call a digital twin of the RBMK reactor at the Smolensk Nuclear Power Plant. Yes, a full 25 years before it became trendy.

In those cozy bygone times, security services hadn't yet gone wild, so the results comparing real operating modes with model results could be freely obtained at the institute and even published in scientific journals and presentations.

And now we can proudly show slides from 2004 comparing the transient process during emergency protection mode #5 (AZ-5 — reducing reactor power by 50%), calculated in PK MVTU and obtained on a real RBMK reactor.

From Nuclear Reactors to Gas Storage

Around the same time at Gazprom, dreams hadn't yet come true because the American swindler Browder and his accountant Magnitsky were still trying to buy up shares of the national treasure through shell companies. And if money appeared anywhere near scientific organizations close to Gazprom, it was only by accident. So accidentally, in one of the divisions of LLC "Podzemgazprom," a task arose to optimize the operation of underground gas storage facilities, and money accidentally appeared there.

In those hungry times, if you had money, either bandits, prostitutes, or hungry scientists would come to you. Bandits couldn't come because this LLC was on the territory of the Kurchatov Institute, which has radioactive materials, military guards with barbed wire and a control track. Prostitutes weren't particularly allowed in either, being a strategic facility. That left hungry scientist-mathematicians with third-level security clearance from the "Nuclear Power Plants" department. You might ask — what do nuclear reactors have to do with gas storage? But when you want to eat, you'll contort yourself in ways you never imagined.

"You need a software complex for simulating underground gas storage in rock salt?"

"We just so happen to have one!"

"Hold my beer, I'll just change the splash screen."

Thus PK MVTU was transformed into PK MPKHG (Underground Gas Storage Simulation) and was verified against real data from a real gas storage facility.

Using PK MPKHG, a computational model of the extraction process at the Yerevan Underground Gas Storage facility was created, which included all underground reservoirs, wells, and surface equipment (pipelines, valves, etc.) of this storage facility. The experimental data obtained at the Yerevan UGS in 1986-1989 were used as input data for calculations.

The implementation of the created methods as a software complex was made possible thanks to the participation of Ph.D., Associate Professor of BMSTU Kozlov O.S.

What could nuclear reactors and gas storage possibly have in common? Inexplicable but true! Mathematical simulation and optimization of control systems are done by the same product and the same people — for both nuclear reactors and gas storage. As the saying goes, a bad dancer blames his equipment, while a good one makes it work! The Soviet mathematical school allows solving any problems in any area of science and technology.

The Bushehr NPP Project

For me, the most amazing fact in this entire story is that the software development was conducted in spare time from the main job, without any commission, by a UTS professor. Oleg Stepanovich Kozlov worked as a professor at the department, and his main duty was to teach idiot students — which, as I experienced firsthand, he did brilliantly. Other development team members worked in various places, often at other design organizations. Yet the team continued developing the PK MVTU software product, essentially in their free time from their main work, and then applying it in their projects.

One of the next major projects was creating a full-scale dynamic mathematical model for the Bushehr NPP. It should be noted that even back then, Iran was under sanctions, and a bunch of "partners" couldn't get into this project to grab a piece of the Russian NPP money. Moreover, even Ukrainian turbine builders from Kharkov were too scared to work on it.

In many other NPP construction projects abroad, effective managers happily included Western suppliers in projects so they didn't have to worry as much. For example, for Chinese NPPs with our reactors, Siemens made the control system. Our VNIIA im. Dukhov honestly purchased licenses from Siemens AG for the TPTS51 process control software and hardware, but for the Chinese NPP they still had to bring in the Germans.

Legend has it that Siemens, having sold licenses for TPTS51 process control to our institute, told the Chinese that the stupid Russians bought obsolete dinosaur garbage, while the best and most modern technologies the Germans kept for themselves. So the Chinese demanded that their VVER-1000 reactor get Siemens process control. If our designers had had the guts, they would have made the Chinese buy our process control too, but the spinelessness of defective managers prevented it.

With Bushehr NPP — it was a different story. Maybe Siemens would have loved to stick their controllers into this project and grab some money, but Uncle Sam's sanctions already prevented that.

An interesting situation emerged. A new project where you couldn't use old Soviet ready-made automation solutions because in the 90s all these developments had become deeply obsolete. For instance, the block control panel monitoring and control equipment was built on archaic means: pointer instruments, chart recorders, light indicators, individual equipment control switches, etc.

The Soviet NPP block control panel (BShchU) was a wall with hundreds of pointer instruments, indicator lights, and thousands of buttons, switches, and toggles. And as I mentioned above, there are no mass or power problems at NPPs, so adding a couple of monitoring systems and a dozen buttons during modernization for improved safety was no trouble at all.

On the other hand, there were no Western companies in the project — companies that didn't have a 10-year gap in technology development — to provide ready-made solutions. Essentially, we needed to quickly reinvent a bicycle from scratch that was already roughly ready in the West.

If it seemed to you that this situation is suspiciously familiar, you're not wrong! This was exactly it — the notorious import substitution, 30 years before it became a trendy sport.

The NPP Control System Testing Facility

Per IAEA requirements, at the center of the NPP process control system should be an integrating component — the Upper Block-Level Computing System (SVBU), which should centralize information flows and provide NPP operational personnel with convenient, reliable, and fast NPP control means. SVBU should be the primary monitoring and control tool for normal operation systems. This was a new solution for domestic nuclear energy in 1997.

Think about it: 1997, three years after the parliament was shelled, bandits are shooting each other in the country. The GKO pyramid is about to collapse, and here you need a SVBU project on new principles.

Everything was developed there, absolutely everything: a real-time operating system based on Linux, a proprietary programming language called ABIS for describing upper-level control algorithms.

Using the ABIS language, the "OPERATOR" software platform was developed, implementing SCADA system functions for large-scale facilities (over one million signals): with continuous, non-stoppable operation (over 30 years); with enhanced reliability, safety, and cybersecurity requirements; capable of integrating lower-level software and hardware complexes of various types, both imported and domestic, into a unified process control system.

And all of this needed to be tested and debugged. Anyone who has ever programmed anything knows that writing code is the simplest and smallest part of the job, while making that code work correctly is a separate sport. Especially when this software will control a nuclear power plant. How do you test all of this, where do you get over one million signals?

The problem was that to properly debug the SVBU, you needed a ready lower-level control system that supplies data to it. But the actual TPTS-based control systems were distributed. To assemble and debug the new SVBU, you'd need to gather all the racks of this control system, which were still being designed and manufactured. What to do?

The idea emerged to assemble the process control algorithms as a mathematical model that would provide the SVBU with all necessary information, thus enabling system verification across all operating modes. Nobody had done anything like this before.

Is this even possible? Everything is possible if you have the Soviet mathematical school and PK MVTU with a development team led by Oleg Stepanovich Kozlov. At this moment, the project full-scale dynamic mathematical model (PPDMM) "Raduga-EU" was born, where the "Raduga" program was used for neutron physics and coolant flow simulation in the active zone, the TRR program for turbine simulation, and all first and second circuit algorithms were assembled in PK MVTU.

Besides unifying mathematical models into a single complex, PK MVTU — the only simulation program in the nuclear industry at that time with a graphical interface under Windows — was used to create control video frames for displaying mathematical models.

In PK MVTU, an editor was created where users drew the schematic diagram of the model, and you could immediately see what was flowing where, what was on, what was off, and where the system wasn't behaving as designed. Essentially, this was the same operator video frame, but for the model.

In this project, another brilliant idea was implemented for the first time. All existing calculation programs for NPP safety justification up to 1994-1997 were written for the command line, and the model for calculation was created as a text file describing the geometry of the designed installation.

Let engineers create a schematic of the installation, set element parameters (diameters, roughness, resistance, etc.), and all the necessary text files will be automatically created by a model generator! And the drawn model would simultaneously display process parameters during calculation and provide control for convenient debugging.

With one shot, not two but five rabbits were killed:

• No need to learn how to create a complex NPP model in a text file in some unknown language.
• The model as a schematic diagram is itself a document understandable to any process engineer-designer.
• The model during calculation displays the process like a video frame — debugging speeds up many times over.
• No changes are made to the calculation software itself. Certified programs work as before.
• From the diagram, you can control the model like from an operator's panel for testing and debugging NPP operating modes.

The Legacy That Endures

It turned out that all atomic institutes had been writing simulation software since 1986. By 2000, there was already more than enough of this code, almost all written in Fortran or C, actively used and containing a mountain of verified solutions. Meanwhile, learning input languages for creating models was like learning a second foreign language. So the thermal-hydraulic code everywhere was like a suitcase without a handle: too heavy to carry, too valuable to throw away.

And after the 90s, a new generation arrived at all enterprises who couldn't even write in a regular language, let alone a specialized one. And those who could quickly learn a programming language went straight to Microsoft, Yandex, or Google, where they were paid much more.

Once again, the gang of mathematician-engineers with PK MVTU came to the rescue. We take PK MVTU and your old Soviet battle-tested calculation code. And with a flick of the wrist, we transform model descriptions in the incomprehensible language of an ancient civilization into schematics understandable even to a novice — thermal-hydraulic, electrical, logical schematics or functional block diagrams.

And this isn't just in Russia — exactly the same situation exists with nuclear calculation codes in other countries. Here's an example from Germany in 2024.

The Bittersweet Aftermath

Naturally, after the Bushehr NPP process control testing facility proved its viability, as always, the uninvolved were rewarded and the innocent were punished.

On other projects without sanctions, German Siemens got into the projects. But even in the photos, it's clear that the import-substituted Bushehr NPP control panel from the 90s looked more modern than its Western counterpart from Siemens of the same era.

As the country crawled out of the 90s crisis, effective managers in Russia began purchasing Western software everywhere. And on the next NPP testing facility, instead of "Raduga-EU," they used an American training system. But the funniest thing is that the graphical data preparation system for the American simulation system was once again purchased from the PK MVTU developers.

And 10 more years later, I was at a seminar where there was a presentation about the successes of the NPP testing facility using the American simulation system. The presenter had been a participant in the Bushehr project. During the break, he confessed to me: "What garbage this American system is. The testing facility with 'Raduga-EU' and PK MVTU for the Bushehr NPP — now THAT was really cool."

Import substitution was only about 20 years away.