Online Control

[Guillem-monso]

Hi everyone,

I hope you're doing well. I’m currently exploring the simulator and overall it seems very intuitive and the first tutorial was very helpful to get started.

I would like to find out if this simulator enables online control of the plasma, such as real-time interaction or feedback during operation. It seems to be possible to perform live plotting through the "plot_progress" command, but I could not find the way to implement it and change the input variables simply based on the tutorial example.

Thank you in advance for any guidance or clarification!

[jcitrin]

Hi Guillem,

Apologies for the delay in replying.

We're glad you're having a good experience with TORAX. Please check out our latest release 1.0.1 where it's even easier to get started with the tutorials directly in Colab.

"plot_progress" was temporarily disabled and currently hidden from the user in the latest release docs, since it was using a deprecated plotting mechanism, and we haven't gotten around to the reimplementation with the standard plotting library. However, it was more of an illustrative feature and TORAX runs are typically fast enough such that post-run plotting should be sufficient for most needs. In fact, TORAX runs slower with "plot_progress" since the bottleneck becomes the plotting itself.

In any case any real-time interaction and feedback would be through automated methods rather than human interface.

Having TORAX within a plasma control system for various use-cases is a possible future application, as done previously by e.g. RAPTOR [https://iopscience.iop.org/article/10.1088/0029-5515/51/8/083052]. It would require some technical modifications to how the code is run and compiled but is likely feasible with some effort. It's fundamental speed is sufficient. If you have specific questions can ask @felicif who has a lot of experience with this.

[theo-brown]

I'm also interested in this.

I think it should be simple to do a somewhat ad-hoc controller interface. Looking at the main loop, you could imagine defining a class MyController that simply modifies the current_state object after each call to step_fn. I am not sure how that would affect JIT, however, so you could experience major slowdowns.

Given the expertise of the team at Deepmind (e.g. previously using RL to develop controllers for magnetic coils) I don't think anyone would be surprised if they were working on things vaguely in this direction.

[felicif]

Hello, reading @Guillem-monso's original question, I'm thinking that you actually mean doing simulations of feedback control which requires the ability to run TORAX as a time stepper, stepping a controller at the same time and closing a feedback loop?

[Guillem-monso]

Dear all, thank you very much for your dedicated answers; @felicif rephrased my point perfectly. What required technical modifications do you and @jcitrin think that would need to be implemented in how the code is run and compiled in TORAX to enable closed feedback control? For example:

• Set control inputs as dynamic: Set actuator inputs (e.g., Total plasma current) as dynamic parameters to avoid recompilation between steps.
• Insert control logic in sim loop: Enable to call a controller function after each step to update inputs based on outputs. What do you think of @theo-brown's implementation proposal?

Regarding the simulator of choice, I previously considered using other simulators similar to the one suggested by @jcitrin, but these simulations are typically computationally intensive, difficult to synchronize with external controllers and sensitive to communication latency. I liked a lot the idea of using TORAX given that ML-Surrogates seem faster, easier to integrate and scalable.

[jcitrin]

The building blocks in the internal API are in place to do this relatively easily, but we haven't exposed these building blocks to the public API yet. You can still give it a go however. I'll sketch out how. On order weeks we can provide an example tutorial of this, and also within a couple of months hope to modify the public API and refactor some internal workings to make this even easier out of the box. As an alternative in the meantime, we can also suggest using the RAPTOR control-oriented modelling code which already supports this out of the box.

Sketch:

run_simulation.py (part of public API) does the following:

1. Initializes the state, initializes all the physics models and solver algorithm and constructs the SimulationStepFn . The SimulationStepFn is a key object in TORAX that given a set of physics models and solver, advances the simulation by a single time step.

2. Takes all the user data from the config (geometries, actuator waveforms, etc) and constructs the static_runtime_params_slice and dynamic_runtime_params_slice_provider. The "provider" is a Callable that provides a slice of various simulation parameters, e.g. plasma current, heating power, etc., at any given time. These parameters are all provided by the config.

3. Passes the objects from steps 1 and 2 into the run_loop, which iteratively calles the SimulationStepFn.

To include a controller, an idea could be to introduce a new controller function before calling the SimulationStepFn. This function would depend on current state (or history of states if desired), and modify the dynamic_runtime_params_slice_provider before supplying it to the SimulationStepFn.

This can be experimented with e.g. in a Colab, copying out the relevant parts of run_simulation.py and run_loop.py , and adding a controller.