How mathematics helped survive in the 90s

Perhaps it was because I spent my childhood near the Smolensk Nuclear Power Plant and got a dose of radioactive emissions from the Soviet RBMK-1000 reactor. Or maybe it was because, during my teenage years, after being expelled from the 8th grade for antisocial behavior, I enrolled in the Bryansk Machine Engineering College. There, one of my teachers boasted that he had applied to Bauman - no, he didn’t manage to get in, but he considered the attempt itself a significant achievement. Apparently, this left an indelible impression on the immature mind of a 15-year-old nerd. And when I made some money from the wild trading during the collapse of the USSR, I decided that I should study at Bauman and become an engineer.

During those hungry times, everyone at the university survived as best they could. The university paid practically nothing at all. Some gave up teaching and went to work wherever they could find luck, some in their field or something close, while others worked wherever they had to. One of our instructors worked part-time as a sales representative and offered me, as a capable and promising nuclear engineering student, to also deliver cookies and waffles to stores. But by that time, I was already a former shop owner and didn’t want to engage in such nonsense. I wanted to be a scientist or at least an engineer (Spoiler: I didn’t succeed, and American corruption turned a physics engineer into a low-level coder, as I wrote about earlier).

The choices for part-time jobs for freshmen in the 90s were not great: sports, trading, crime, and all of it without leaving the walls of our university. Imagine the scene: at night, trucks loaded with alcohol pull into the back yard of the N.E. Bauman Sports Complex, where future designers of rocket and nuclear technology unload crates of vodka, beer, and gin and haul them into the basement of the sports complex. And there, future weapons designers stick counterfeit excise stamps onto bottles of alcohol with BF glue. On one hand, sports and alcohol are incompatible; on the other hand, loading and unloading alcohol effectively replaced fitness, plus it paid pretty well.

At that time, a remarkable associate professor Oleg Stepanovich Kozlov was working at the department, teaching us the subject "Management in Technical Systems." For some reason, he suddenly decided that earning a living should not be through trade, but through software development. The department was dealing with nuclear reactors and preparing hardware designers. Even then, there were trendy and youth-oriented departments related to IT. But the nuclear engineers and energy specialists were considered experts in nonsense and vapor, having nothing to do with programming and IT. However, Oleg Stepanovich did not care about this; for extra income, he began developing a new program for dynamic modeling 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 the author of mathematical methods, he is widely known in narrow circles around the world. A simple search by his last name is enough: for example, in the 2025 report on innovative methods for calculating stiff problems, there is a reference to his 2010 work, where he is noted as the founder of one of the two main methods for solving the stability problem for stiff systems.

The tumultuous 90s. At that time, the world was painfully transitioning from DOS to Windows 3.11, while in the depths of 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 those legendary times, most people in the stunned country tried to survive somehow, while a minority sought to squeeze or even take things for themselves personally. A group of engineer-mathematicians, like the last samurai of Soviet education, continued to do what needed to be done, come what may. Like the last legionnaires of the empire, they fulfilled their teaching duty. But to eat, they simultaneously created a new software product in their free time from their main work.

A software package for solving problems related to modeling control systems with a wildly fashionable graphical interface at that time.

The name of the product was maximally patriotic and originally traditional: Software complex "Modeling in Technical Devices" (PC "MVTU"). This refers to the old name of Bauman University - "Moscow Higher Technical School" (MVTU). In those legendary times, all, absolutely all teachers and staff at Bauman considered the LGBT community to be extremists under the new rector for changing the proud name "Moscow Higher Technical School" to the ordinary, gray, and dull "Moscow State Technical University." The Bauman School was unique in the entire USSR, while after the collapse of the USSR, universities proliferated like fleas on a stray dog. Any former fence-building technical school in any small town proudly began to call itself a university. The Bauman students have their own pride; they look down on the bourgeoisie, believing that the word "school" should be preserved in the name. Although now, I think the rector was indeed right back then. Those idiots who came to power after the collapse of the USSR could easily confuse a Higher Technical School with some kind of vocational technical school and shut it down completely. And the buildings - the former palace from the times of Catherine and the Stalinist tower - could have been turned into a fashionable casino-hotel with blackjack and hookers.

And so, in such conditions of chaos and uncertainty, our heroes write their own software for modeling technical systems.

Thanks to Oleg Stepanovich's iron eggs, the first version of the MSTU PC on 286 computers under Windows 3.1 was implemented into the educational process on the fly. Every year, three groups of students from the department, about 60 people, diligently went to the laboratory throughout the academic year, sat down at the computer, and "used the MSTU PC." Students, like mice, cried, got pricked, but continued to eat the cactus - performing laboratory work on buggy computers running buggy Windows 3.1 in the buggy version of the MSTU PC version 1.0. And I was also among those students. There was no greater joy for us, young idiots, than to find a bug in the MSTU PC so that Oleg Stepanovich would come over and say: "Holy crap, look how the girls dance!" This meant that there would be discussions in the development team in the evening and someone would get beaten up. Later, when I became a developer in this team, I was the one getting beaten up - for my mistakes that surfaced when the stupid clumsy students tried to use my magical components in their labs.

As a result of such fierce testing, the quality of the software quickly improved to the point that 25 years later, in one of the design bureaus, a sprightly old man caught me by the tie in the corridor and said: "This MSTU PC 3 was a great product, it was written by real engineers, and your shitty SimInTech is written by some half-baked amateurs."

In 2025, I was shown a drilling rig simulator that started up and worked! Here's, by the way, the video:

Having received an excellent product in which one can solve educational tasks in automatic control theory and more, the authors tried to sell it to universities, but alas, there was no money in the universities at that time, so it had to be given away for free. And since everything worked stably and excellently, to this day, the MSTU PC is the first software product in the former USSR in terms of the number of published university methodological materials. Even books on MSTU were published by independent authors in various universities. And even now, a search for the MSTU PC yields a whole list of laboratory works from different authors in various corners of the former USSR.

After 1998, producers of Western software flocked to the country in search of money. To begin with, the global backstage of reptilians, represented by Bill Gates and Microsoft, taught users to pay for software not at "Gorbushka," but at the cash register. They taught this with the whip in the form of "mask shows" with riot police and the carrot in the form of kickbacks that could be recorded as expenses in the accounting of Western companies. Then came the producers of engineering software, and a bloody massacre began.

It was like a horde of nomads attacking peaceful farmers. Western companies bought engineers in bulk for their sales teams, just as Genghis Khan's Mongols drove conquered peoples into the fighting units of their horde. Boeing bought Russian engineers from the collapsed aviation industry for pennies and made these engineers do menial work of redrawing paper blueprints in the CAD CATIA.

Western software producers opened offices in Russia, where conquered natives sat and exchanged license files for hard currency. Since the conquerors offered distribution discounts to the natives, a crowd of people rushed to their offices to participate in the plundering of territories.

I myself participated in this celebration of life by selling French CAD CATIA.

Perhaps the MTU PC would have also faded into oblivion, like many other products. Especially since, back in 1994, when developers at MGTU had just started working on MTU, Mathworks had already rolled out its version on MATLAB - Simulink. This very Simulink would, ten years later, steamroll through universities in Russia and seat almost all professors of automatic control theory in front of Simulink diagrams, just as the English had seated the Chinese on opium in the 19th century, or how, in retaliation, Chinese traders are getting Americans hooked on fentanyl in the 21st century, while the rest of the world is hooked on Chinese electronics and mass consumer goods.

Meanwhile, domestic development was slowly but surely dying like the cruiser Varyag. Although there were quite a few developers. For example, on the Exponeta website, before it was bought by LGBT extremists, there were more domestic developers than Western ones in the software section back in 2006. The internet, notably, remembers everything:

https://web.archive.org/web/20060615214736/http://www.exponenta.ru/soft/Others/others.asp

And, quite possibly, the MVTU PC, despite its coolness—indeed, it was really cooler than any other Western competitors—would have quietly faded away like many other domestic modeling programs.

But there was no happiness, and misfortune helped. The developers of the MVTU PC were saved by the fact that earlier, in 1986, the Soviet RBMK reactor in Chernobyl failed the tests imposed by curious Soviet scientists and exploded. Since then, specialists in the atomic field have had a new definition of the degree of intimidation - "scary as RBMK."

After Chernobyl, all requirements for designed reactors included a mandatory part of the project - an in-depth safety report, which required mathematical modeling of processes. Without this modeling, the project could not be defended. Whether you want to or not, when asked by regulatory authorities, "Will it blow up?" - you had to respond, "It shouldn't," with mathematical proof in hand in the form of calculations using a mathematical model. Thus, nuclear reactor designers became accustomed to modeling technological processes.

And it so happened that the chief 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 through the subject "Control in Technical Systems" in lectures and MVTU PC in laboratory work. As was customary at that time, the design institute involved the department in performing tasks. One of these tasks was the modernization of the control system for the RBMK reactor. By that time, the Soviet analog control system for nuclear power plants had already become outdated, and it needed to be replaced with a digital one, but everyone was scared—after all, this was RBMK.

This is where the developers at MSTU got excited. A real, significant task emerged for a real object in the nuclear industry. Why significant? Because, unlike an airplane, car, tank, or even a ship, a nuclear power plant (NPP) has no limitations on the mass of equipment and power supply. This means that designers and engineers of NPPs do not need to worry about how many and what types of sensors to install in the control and safety systems. As many as the designer needs, that's how many we will install, and if we need twice as many (for redundancy) and a little more! Then, according to safety requirements, we will double and triple everything again. This is called a triple-channel safety system. There's plenty of room at the NPP for everyone. As a result, the control and safety system transformed into a monstrous entity with thousands of pages of diagrams, which is not only mathematically difficult to model but also hard for a single person to even visualize.

Interestingly, in the first atomic reactor, the safety system consisted of a control rod suspended by a cable over the active zone and an axe lying nearby. The axe had to be used to cut the cable for an emergency drop of the rod and reactor shutdown. However, this was an American reactor. In a Soviet reactor, that axe would have been "redistributed" before the end of the first shift. Therefore, in Soviet reactors, engineers created automation from the very beginning: first analog, then as computers became available - digital. And while for analog automation and the first calculators, it was still necessary to think about the number of signals, algorithm complexity, and memory volume, with the advent of industrial computers, there were no more restrictions: a thousand signals, a million, or even ten million; there were no limits on mass and power consumption either. The computer can handle it all.

And so at NIKIET, there arises the task of replacing the analog Safety Control System for the RBMK reactor with a digital one. But before changing it, it would be wise to test it on a model; not only because this is a requirement from the IAEA, but also simply because it's a bit daunting. As experienced engineers and programmers say: "If it works, don't touch it." But here, there's no way around it; the service life of the ferrite core memory has come to an end, it must be addressed, it must be done.

In those hungry times, if you had money, either bandits, prostitutes, or starving scientists would come to you. The bandits couldn't come because this LLC was located on the territory of the Kurchatov Institute, which has radioactive materials, military guards with barbed wire, and a control and tracking strip. Prostitutes were also not really allowed, as it was a strategic facility. Only starving mathematicians remained, who had a third-level access certificate from the "Nuclear Power Plants" department. It seemed, where are nuclear reactors and where are gas storage facilities? But when you want to eat, you can stretch yourself in unexpected ways. He who feeds the girl dances with her. Or any whim for your money.

— Do you need a software complex for modeling underground gas storage in rock salt?

— And we just happen to have it!

— Hold my beer, I’ll change the intro now.

As they say, find three differences:

Thus, the MSTU PC turned into the MPHGC PC and was verified on real data from a real gas storage facility.

…Using the MPHGC PC, a calculation scheme for the selection process from the Yerevan UGS was created, which includes all underground reservoirs, wells, and surface equipment (pipelines, valves, etc.) of this storage facility. Experimental data obtained at the Yerevan UGS in 1986-1989 were used as initial data for the calculations…

…The implementation of the created methods in the form of a software complex became possible thanks to the participation in this work of Ph.D., Associate Professor at Bauman Moscow State Technical University O.S. Kozlov…

It may seem strange, but what could possibly be common between nuclear reactors and gas storage facilities? It’s inexplicable, but it's a fact! Mathematical modeling and optimization of control systems are done by the same product and the same people — for both nuclear reactors and gas storage. As they say, a bad dancer is hindered by eggs, while a good one is helped! The Soviet mathematical school allows for solving any problems in any fields of science and technology.

The most surprising fact in this whole story for me is that the software development was carried out in the free time from main work, without any order from the instructor of the UT department. Oleg Stepanovich Kozlov worked as an instructor in the department, and his main duty was to teach the clueless students — which he, as I experienced myself, did excellently. Other participants in the development worked wherever, often in other project organizations. At the same time, the team continued to write the software product of the MSTU PC, essentially in their free time from main work, and then apply it in their projects.

One of the next cool projects was the creation of a full-scale dynamic mathematical model for the Bushehr nuclear power plant. It should be noted that even back in those distant times, Iran was under sanctions, and a bunch of "partners" could not get into this project to take a bite of the money for Russian nuclear power plants. Moreover, on this project, even Ukrainian turbine builders from Kharkiv were too scared to work.

In many other nuclear power plant constructions abroad, efficient managers were more than happy to include Western suppliers in the projects to reduce hassle. For example, for Chinese nuclear power plants with our reactors, Siemens made the control system. Moreover, our VNIIPA named after Dukhova honestly bought licenses from JSC "Siemens" for the software and technical means of ACS TP TPTS51, but for the Chinese nuclear power plant, it still required involving the Germans.

There is a legend that Siemens, by selling the licenses for the ACS TP TPTS51 to our institute VNIIRA named after Dukhov, told the Chinese a story that the stupid Russians bought outdated dinosaur crap from him, while the best and modern technologies were kept by the Germans. And that’s why the Chinese demanded that we install Siemens' ACS TP on our VVER-1000 reactor. If our designers had any guts, they would have made the Chinese buy our ACS TP as well, but the softness of defective managers got in the way.

With the Bushehr NPP, it’s a different story. Maybe Siemens would have been happy to get involved with their controllers in this project and squeeze some money out of the Russian fools, but Uncle Sam's sanctions wouldn’t allow that back then.

An interesting situation arose. A new project where old Soviet ready-made developments in automation could not be used because all these developments became deeply outdated in the 90s. For example, the control and management tools of the block control panel of the nuclear power plant were created based on archaic means: analog instruments, recorders, light indicators, individual equipment control keys, and so on.

The BShU (block control panel) of the Soviet NPP is a wall with a hundred analog instruments, indicator lights, and thousands of buttons, switches, and toggle switches. Moreover, as I wrote above, there are no problems with mass and electricity at the NPP, so adding a couple of control systems and a dozen buttons during modernization to improve safety is really not difficult at all.

In the end, the developers' imagination was only limited by the size of the room and the panels. One can compare the number of buttons in two photographs of the BShU of the Soviet reactor: at the beginning of operation and after several modernizations. As they say, progress is evident, or rather, on the front panel of the panel, where the buttons are crammed together like keys on a PC keyboard, only their number approaches the number of characters in the Chinese language.

On the other hand, there are no Western companies in the project that did not experience a 10-year gap in technological development to take ready-made solutions into the project. Essentially, we needed to quickly invent the wheel from scratch, which was already roughly ready in the West. For example, at that time, the BShU of the French NPP looked something like this:

If you thought that the situation seemed suspiciously familiar, you were not mistaken!
This was precisely it, the infamous import substitution, 30 years before it became a trendy and youthful sport.

…According to the requirements of the IAEA, an integrating part must be located in the centralized automated control system – a high-level block computing system (HLBCS), which should centralize information flows and provide the operational personnel of the NPP with convenient, reliable, and fast means of controlling the NPP, solving both traditional tasks and tasks that enhance the safety level of the NPP at a modern level.
The HLBCS should be the main means of monitoring and managing normal operation systems. This was a new solution for domestic nuclear power in 1997…

Think about it: 1997, three years after the shooting of the parliament, in a country where bandits shoot each other and blow up Berezovsky. The GKO pyramid was already ready to collapse, and here a project for the HLBCS based on new principles was needed.
And everything was developed from scratch: a real-time operating system based on Linux, its own programming language ABIS!!! for describing high-level control algorithms.

“...Using the ABIS language, the software platform ‘OPERATOR’ was developed, implementing SCADA-system functions for large-scale objects (over one million signals):
— with continuous, non-stop operation mode (over 30 years);
— with increased requirements for reliability, safety, and cybersecurity;
— capable of integrating various types of lower-level hardware and software complexes, both foreign and domestic production, into a unified automated control system…”

And all this needs to be tested and debugged. Everyone who has programmed something at least once knows that writing code is the simplest and smallest part of the work, while getting that code to work properly is a separate sport. Especially since this software will control the NPP. How to test all of this, where to get over one million signals?

The problem is that in order to effectively debug the control system for the nuclear power plant, a ready-made lower-level management system is needed to supply data for it. However, the technological control systems based on the TPTS are actually distributed. To assemble and debug a new control system, it is necessary to gather all the stands of this control system, while they are still being designed and manufactured. What should be done in this situation? Sit back and wait for all the elements to be assembled, and then start putting everything together and debugging at the last moment before delivery, or come up with something?

The idea arises to gather the algorithms of the automated control system for the thermal power plant into a mathematical model, which will provide all the necessary information for the control system, thus ensuring the verification of the system in all modes. Until this point, no one had done anything similar: it is one thing to develop control algorithms and complicate the control system by gradually adding sensors here and there during the modernization of a real nuclear power plant; it is another thing to assemble all of this into a unified model of the nuclear power plant and make it work together with the real control system.

Is this even possible? Everything is possible if you have a Soviet mathematical school and the MVTU computer with a team of developers led by Oleg Stepanovich Kozlov. Part of the MVTU developer team was already working at the Moscow "Atomenergoprojekt" at that time. At this moment, the project for a full-scale dynamic mathematical model (PDM) "Rainbow-EU" was born, where the "Rainbow" program was used for simulating neutron physics and coolant flow in the active zone, the TRR program was used for simulating the turbine, and all algorithms for the first and second circuits were collected in the MVTU computer.

Programs for simulating neutron physics and thermohydraulic processes were already ready at that time. They were used for safety justification, but assembling a complete set of control algorithms and integrating all these programs into a single model was something that had never been done before. But there are no heights that communists, armed solely with the only correct theory of automatic control and the MVTU computer, could not conquer.

In addition to combining mathematical models into a single complex, the MVHTU PC was the only simulation program in the nuclear industry at that time with a graphical interface for Windows, which was used to create video frames for controlling the display of mathematical models. For example, this is what a generalized video frame for the turbine model in TRR looked like.

An editor was created in the MVHTU PC, where users could draw the schematic of the model, and it was immediately clear what was flowing where, what was turned on, what was turned off, and where the system behaved differently than intended. Essentially, this is the same video frame for the operator, but specifically for the model. It displays not what the operator needs to control the reactor, but what the developer needs to understand where they made mistakes when creating the model. And if an algorithm model is being created, errors in these algorithms can be identified during the creation stage. As a result, when creating control algorithms in the MVHTU PC, their verification was carried out simultaneously along with the test model for the SVBU.

This project implemented another brilliant idea for the first time.

The fact is that all existing calculation programs for justifying the safety of nuclear power plants by 1994–1997 were written for the command line, and the model for the calculations was created in the form of a text file that described the geometry of the designed installation. For example, the diagram depicted in the figure above was created as a text file in a format understood by the TRR calculation code, as shown in the following figure:

This text had to be typed in a text file with pseudographics, necessarily in the "Cyrillic IBM866" encoding. What is particularly amusing here is the explanation accompanying the text:

“...If the channel calculation is performed in another program, then the complexes are passed in the REGOUT array in the following sequence: ROGH, ZROF, SLF, Pnas, Hout, Cout, Qto, Tout. The indicator is a negative value of the number of elements in the channel (Nel), and abs(Nel) is the address ROGH in the REGOUT array (ROGH = REGOUT(abs(Nel)), ZROF = REGOUT(abs(Nel)+1), etc.). If the value of the element number with the pump (Nnas) is negative, then the pump head is determined in meters of pumped liquid…”

When the model is used for safety justification calculations, one can imagine a person mastering this data input method with all these rules and creating models and issuing reports. But when you need to quickly create a model for a newly designed reactor to be used for modeling modes for debugging the control system, such an input method cannot be called optimal — it takes months, if not years, just to master it.

Moreover, creating a large model requires involving specialists from different fields, not just calculational experts. And as we know, a true specialist is like flux: their expertise is one-sided. Forcing a turbine management specialist or a control systems engineer to master a new model representation language is like teaching an adult bear to dance.

At the same time, the calculation codes — both "Rainbow" and TRR — have already been tested in many projects, countless calculations have been performed on them, and changing their input method will also require significant time investment.

It would seem that there is no way out, everything is lost — the mold is removed, and the client leaves. But here, like Chip and Dale, the developers of the MSTU PC rush to the rescue. They originally created the package as a visual development environment. To prevent new users from suffering while creating models in text format in an unknown programming language, we will provide them with a tool for creating models in the form of understandable diagrams.

Let engineers create the schematic diagram of the installation, set the parameters of the elements (diameters, roughness, resistances, etc.), and all the necessary text files will be generated automatically by the model generator!

And to avoid getting up twice, the drawn model will simultaneously display the process parameters during the calculation and provide control over this model for debugging convenience.

With one shot, not two hares are killed, but as many as five. This is no longer hunting, but poaching, and the MSTU PC here is like a prohibited weapon of mass destruction:

No need to study how to create a complex nuclear power plant model in a text file in an unknown language.

The model in the form of a schematic diagram is itself a document that is understandable to any design technologist, and they can be involved in its creation.

The model during the calculation process displays the process like a video frame — debugging is accelerated many times over.

No changes are made to the calculation software itself. The certified and authorized programs "Rainbow" and TPR operate as before. Additional verification of models is not required.

The diagram allows you to control the model like an operator's remote for testing and debugging the modes of operation of the NPP.

As a result, the NPP model during creation looks as shown in the figure:

And when we run the calculation, the model looks exactly like shown in the next figure:

The fourth hare initially seemed like collateral damage. Well, they did it to collect models faster, so let it be.

But later, with the development of the software, this hare played a key role.

It turned out that all nuclear institutes started writing modeling software back in 1986. Right from the accident, they rushed to write the calculation thermal-hydraulic code. By the year 2000, there was already an overwhelming amount of such code, and not only was almost everything written in Fortran or C, but it was also actively used and contained a bunch of ready-made, and most importantly, practically tested and verified solutions. At the same time, learning input languages to create models is like learning a second foreign language. Therefore, the thermal-hydraulic code was everywhere like a suitcase without a handle: hard to carry, and sad to throw away.

And after the 90s, a new generation of young idiots comes to all enterprises, who not only can't write in a special language — they can't even read in a regular language, let alone write in a special one. And those who can quickly learn a programming language immediately go to Microsoft, Yandex, or Google, where they are paid much more.

What to do? How to preserve the secret knowledge of great ancestors?

And here again, a gang of mathematicians-engineers from MSTU comes to the rescue:

We came to you for an hour,

Hello, bonjour, hello.

And you rather love us!

You are very lucky!

We take the MSTU PC, your old Soviet combat-tested calculation code. With a simple motion of the hand, we turn the descriptions of models in the incomprehensible language of an ancient and more advanced civilization into understandable thermal-hydraulic, electrical, logical schematic diagrams or functional-block diagrams of algorithms, even for a young moron.

And it's not just in the backward country of Russia — the same situation exists with calculation atomic codes in other countries. I wrote about the USA here...:

Here's an example from Germany from 2024 — you won't believe it, it still works. https://t.me/Tech_Petuhoff/643

The first combat application of this idea was made in the turbulent 90s.

It is clear that according to the laws of the genre, after the testing ground for the Automated Control System (ACS) "Bushehr" proved its effectiveness, as always and everywhere, there began the awarding of the uninvolved and punishment of the innocent.

In other projects where there were no sanctions, German Siemens got involved in the projects. Thus, in the Chinese VVER projects and ACS, the BSC was handed over to the Germans. But even in photographs, it is clear that the imported BSC of the Bushehr NPP from the 90s looked more modern than its Western counterpart from Siemens of the same time, as they say, feel the difference:

As the country crawled out of the 90s crisis, effective managers in Russia began to purchase Western software everywhere they could and couldn't. And at the next testing ground for the ACS to model NPPs, instead of "Rainbow-EU," they used an American training system, previously called S3. But the funniest thing is that the graphical data preparation system for the American modeling system was once again bought from the developers of the MSTU PC.

And another 10 years later, I attended a seminar where a report was given on the successes of the ACS testing ground on the American modeling system. The speaker was a participant in the Bushehr project. During the break, he confessed to me: "What a nasty American system this is, the ACS testing ground with 'Rainbow-EU' and MSTU PC for the 'Bushehr' NPP — that was really cool."

It was only about 20 years until import substitution.