[chriskanan]

There is a lot of AI research in the nuclear fusion space. For inertial confinement fusion (a competing technology to magnetic confinement fusion, e.g., tokamaks) the National Ignition Facility (NIF) used it for their experiment that resulted in "ignition."

My lab is collaborating with researchers at the Laboratory for Laser Energetics to use AI to improve inertial confinement fusion (ICF). We recently put out this paper [1] using Kolmogorov-Arnold Networks (KANs) to predict the outcome of ICF experiments. Currently, existing physics simulators are based on old Fortran code, are slow, and have a high error between their predictions and actual laser shots, so among other goals, we are trying to build better predictors using neural networks. This is needed since it is hard to rapidly iterate on real data, since they only have a dataset of around 300 ICF shots.

[1] https://arxiv.org/abs/2409.08832

[noobermin]

Here we go with the CS people saying "the old fortran codes are terrible." Yeah, the "high error" between code predictions and laser shots is because LPI is inherently noisy and it's essentially impossible to fully control conditions. I would work on expensive sims for days to weeks and the experiments would see differences that would be off from that from an order or mag because their focal point is off by a micron. There's nothing wrong with the "old Fortran codes," they have the right physics, the problem is the initial conditions are just uncontrollable so that's why simulating these systems is hard.

Codes are not magic, they are physical codes, as in, they generally encode the physics as we understand it relevant to the experiment, so you might as well say our physical models are wrong, which is a much harder bar to clear, you'd have to invalid probably near 100 years of plasma physics. The problem likely is as I said, the experiments are just hard to control and we don't know the correct inputs. It's not like weather forecasting where we can have a weather balloons across the world, we're not able to probe every micron of the target at all times for a plasma temperature and density.

[chriskanan]

Based on what the physicists have told me, the main issue with the Fortran code is that it is SLOW and hard to accelerate. Because the codebase is 30+ years old, much it sounds like it isn't well understood. They think it would benefit a lot from things like GPU acceleration, but that's hard to do with it in its current state.

Otherwise, the major issue is just that it makes a lot of assumptions and has a lot of inaccuracies, but that issue isn't due to Fortran but just because it doesn't capture all of the physics and there is a sim2real gap. So it DOES NOT have the right physics, but re-writing it probably wouldn't result in the "right" physics either.

The main version of the code they run uses 1-D physics (so one spatial dimension), which takes about 8 minutes to run on a modern CPU. The code can't be parallelized without being re-written. Running the 3D version of the code takes 1+ weeks for a single run, and that still has a big sim2real gap.

[phreeza]

I understood the comment as saying the fortran code maybe used some sort of inefficient numerical scheme and/or some inaccurate approximations? Doesn't seem completely outlandish that more modern methods could help there? Of course fortran is not a problem in itself, you are right.

[gauge_field]

In addition to the capabilities of language, usually it depends also on the ecosystem than the language itself (unless you want to write the entire algorithm by yourself for some reason). This is especially true if the algorithms used in the project are well-studied and the efficient implementations are provided. That is probably the reason why using modern/popular tool/language will more likely to perform better.

One of the most prominent example of this gemm. Usually, the state of the art code base on gemm are written C/C++, in terms of implementations in academic papers/github, see e.g. openblas, blis, blasfeo. The same situation applies to CUDA code or accelerator agnostic code e.g. using MLIR. I think it's more a result of how the language allowed people to create an ecosystem + ecosystem created by the people using the language. Sure, you can write Fortran, but if I see more tooling and more other people benchmarking, I can be more sure that the software will be tested more and higher performance etc. For instance, if you look at benchmarks-game, the top results are C/C++/Rust. Instead of making claims like this code is not wrong/right, we should look at the concrete/quantitative results like benchmarking/number of users. As another example, you can check blasfeo paper where they used C code.

I would welcome Fortran benchmarking results. But, I just dont see it being tested enough (in open source/papers/benchmarks) to prefer it over C/C++/Rust.

There are other consequences of this networking issue: availability of docs, finding an question and answer for a problem that you experienced.

[nightowl_games]

Isn't there a lot of daylight between old Fortran code and AI?

What if we rewrote the old algorithms in C with modern techniques? Multitthreading? Or GPU compute? If there's value there, I could do these things. Probably wouldn't take that long

[rnhmjoj]

Rewriting the old Fortran code in C will probably make it slower with new bugs. A smarter thing to do when picking up terrible code written by physicists is to document everything you can, write tests and then start refactoring bit by bit using modern Fortran features (yes, the latest standard is 2023).

Fortran compilers had more than 40 years to become pretty good at generating efficient code; they can make assumptions that are not possible in C (for example, no aliasing) to do so. Besides, most compilers already can do vectorization and autoparallelisation with multithreading, coarrays, and/or openMP, which can be offloaded to a GPU.

[nightowl_games]

> Rewriting the old Fortran code in C will probably make it slower with new bugs.

Then it's not done yet.

[staunton]

The issue isn't that the Fortran code is too slow. The issue is that the problem description is super complicated, hard to measure and very hard to control is ways that noone really understands. However, you can just plug the measurement outputs and system inputs to some controller. This machine learning helps control by jointly modeling imperfections in the physical model, imperfections in the hardware that controls things, and imperfections in the measurements. That's something you just really don't want to even attempt writing by hand (in whatever programming language).

[chriskanan]

This is what they would like to do, but it is hard to get funding for such an effort or to prioritize such work. It sounds like they think it would take a long time, and it wouldn't yield high impact papers from just doing that exercise.

Plus, even after doing that, there would still be a sim2real gap. The goal of our research is to use physics informed deep learning and methods with strong inductive biases, combined with transfer learning and low-shot learning to overcome the sim2real gap.

[gauge_field]

I got curious when you said " old Fortran code, are slow, and have a high error between their predictions " Do you have any online reference/docs that explain apis/software/source code related to projects in this area?