Access the full Comsol API#

The primary focus of MPh is to automate the simulation workflow, like running parameter sweeps or optimization routines with customized, Python-powered post-processing. Navigating and altering models via its Python API is possible, see next section, but has some limitations.

However, any and all functionality offered by the Comsol API is accessible via the “pythonized” Java layer provided by JPype, which is exposed as the .java attribute of Client instances, mapping to Comsol’s ModelUtil, as well as of Model instances, mapping to Comsol’s model.

Let’s take this Comsol blog post as an example: “Automate your modeling tasks with the Comsol API for use with Java”. It starts with the following Java code:

import com.comsol.model.*;
import com.comsol.model.util.*;

public class HelloWorld {

   public static void main(String[] args) {

   public static Model run() {
      Model model = ModelUtil.create("Model");
      model.geom().create("geom1", 3);
      model.geom("geom1").feature().create("blk1", "Block");
      model.geom("geom1").feature("blk1").set("size", new String[]{"0.1", "0.2", "0.5"});
      return model;

What it does is, it creates a model, which contains a 3d geometry component that is just a block 0.1 by 0.2 by 0.5 meters in size.

In Python, we would achieve the same like so:

import mph

client = mph.start()
pymodel = client.create('Model')
model =

model.geom().create("geom1", 3);
model.geom("geom1").feature().create("blk1", "Block");
model.geom("geom1").feature("blk1").set("size", ["0.1", "0.2", "0.5"]);

Note how the functional Java code (excluding the Java boilerplate) was essentially copied and pasted, even the semicolons, which Python simply ignores. We named the Python wrapper pymodel and assigned model to the underlying Java object just so we could do this. We had to replace new String[]{"0.1", "0.2", "0.5"} because Python does not know what new means. There, Java expects a list of three strings. So we replaced the expression with ["0.1", "0.2", "0.5"], the Python equivalent of just that: a list of these three strings.

Occasionally when translating Java (or Matlab) code you find in the documentation, or a blog post as the case was here, you will have to amend code lines such as the one above. But they are few and far between. The error messages you might receive should point you in the right direction and the JPype documentation would offer help on issues with type conversion.

The advantage of using Python over Java is:

  • You don’t really need to know Java. Just a little, to understand that occasionally we have to take care of type conversions that JPype cannot handle all by itself. Which is rare.

  • You don’t need to install Java. It just ships with Comsol. You also don’t need to bother with compiling Java source code to Java classes via comsolcompile.

  • You can use Python introspection to understand how Comsol models are “created in code”. The Comsol documentation explains a lot of things, but not every little detail. Either use Python’s built-in dir() or call mph.inspect() to print a pretty-fied representation of a Java object in the model tree.

To save the model created in the above example, we do:'model')

This stores a file named model.mph in the working directory, which may then be opened in the Comsol GUI or be used in any other Python, Java, or Matlab project.

Comsol can be very helpful in creating the Java code corresponding to changes we make to a model. Not only does the GUI provide a function to “copy as code to clipboard” on any node, it also lets us save the entire model as a Java source file, in which the new code can conveniently be found at the bottom.

Busbar example#

“Electrical Heating in a Busbar” is an example model featured in the tutorial of “Introduction to Comsol Multiphysics” and explained there in great detail. The section “Getting the Maximum and Minimum Temperature” demonstrates how to obtain the two temperature extremes within the Comsol GUI.

The following Python code does the same thing programmatically:

import mph

client = mph.start()
model = client.load('busbar.mph')

(x, y, z, T) = model.evaluate(['x', 'y', 'z', 'T'])
(Tmax, Tmin) = (T.max(), T.min())
(imax, imin) = (T.argmax(), T.argmin())
print(f'Tmax = {T.max():.2f} K at ({x[imax]:5f}, {y[imax]:5f}, {z[imax]:5f})')
print(f'Tmin = {T.min():.2f} K at ({x[imin]:5f}, {y[imin]:5f}, {z[imin]:5f})')

This outputs the exact same numbers that appear in the table of the GUI:

Tmax = 330.42 K at (0.105000, -0.024899, 0.053425)
Tmin = 322.41 K at (0.063272, 0.000000, 0.000000)

We could now sweep the model’s parameters, for example the length L or width wbb of the busbar.

Compacting models#

We usually save models to disk after we have solved them, which includes the solution and mesh data in the file. This is convenient so that we can come back to the model later, but don’t have to run the simulation again, which may take a long time. However, the files then occupy a lot of disk space. After a while, we may want to archive the models, but trim the fat before we do that.

To compact all model files in the current working directory, we can do this:

import mph
from pathlib import Path

client = mph.start()
for file in Path.cwd().glob('*.mph'):
    model = client.load(file)

The script in the demos folder of the source-code repository is a refined version of the above code. It displays more status information and also resets the modeling history.

Note that we could easily go through all sub-directories recursively by replacing glob with rglob. However, this should be used with caution so as to not accidentally modify models in folders that were not meant to be included.

Multiple processes#

As explained in chapter “Limitations”, we cannot run more than one Comsol session inside the same Python process. But we can start multiple Python processes in parallel if we leverage the multiprocessing module from the standard library.

import mph
import multiprocessing
import queue

Additionally, we have imported the queue module, also from the standard library, though only for the queue.Empty exception type that it provides.

In this demonstration, we will solve the model capacitor.mph from the Tutorial. We want to sweep the electrode distance d and calculate the capacitance C for each value of the distance, ranging from 0.5 to 5 mm.

values = [0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5.0]

Next, we define the function that we intend to run in every process, i.e. the “worker”. The function sets up the Comsol session when the process starts, then keeps solving the model for every distance value that it receives via a jobs queue. Each time, it evaluates the solution and returns the capacitance via a results queue. It does so until the jobs queue is exhausted, upon which the function terminates, and with it Comsol session and Python process.

def worker(jobs, results):
    client = mph.start(cores=1)
    model = client.load('capacitor.mph')
    while True:
            d = jobs.get(block=False)
        except queue.Empty:
        model.parameter('d', f'{d} [mm]')
        C = model.evaluate('2*es.intWe/U^2', 'pF')
        results.put((d, C))

Each worker will only use one of the processor cores available on the machine, as that’s the whole point: We want to achieve maximum speed-up of, say, a parameter sweep, by having each core work on a job corresponding to one of the many parameter values, which it can do independently of work being done for any other value.

We could also solve this sequentially, one parameter value at a time. Comsol’s solver could then make use of all cores and would also employ some parallelization strategy in its internal computation. But the speed-up would not scale linearly with the number of cores, especially for large numbers of them.

We might use a “parametric sweep”, a feature that Comsol does offer. But by doing this in Python we retain full programmatic control of which parameter is solved for and when. The parameter values don’t have to be hard-coded, they could come from user input or be generated depending on the outcome of previous simulations. For example, this approach lends itself to iterative optimization schemes such as the genetic algorithm or differential evolution, where a batch of simulations would be run for each new “generation”.

Note how the returned results also contain the input parameter. As the worker processes will run asynchronously in parallel, we cannot take for granted that output is returned in input order.

Before we start the computation, we add all parameter values to the jobs queue:

jobs = multiprocessing.Queue()
for d in values:

We also have to provide the results queue, which is of course empty at first.

results = multiprocessing.Queue()

Then we can start a number of workers, say four:

for _ in range(4):
    process = multiprocessing.Process(target=worker, args=(jobs, results))

It may be a good idea to hold on to the process objects and add them to a list processes, just so that Python’s garbage collection won’t accidentally delete them while the external processes are running.

Finally, still in the main process that starts all the workers, we can collect the results. We use a for loop and exploit the fact that there will be as many results as there were jobs to begin with.

for _ in values:
    (d, C) = results.get()

We would then display them, plot them, save them to a file, or whatever it is we do with simulation results.

The complete script, which implements all of the above and also irons out some wrinkles not covered here for the sake of brevity, can be found in the demos folder of the source-code repository. As it runs, it displays a live plot such as the one that follows. It is reproduced here preserving the real time from a run with two workers. Observe how the first two data points do in fact come in out of order.

Live plot of worker pool demo

A more advanced implementation may use a class derived from multiprocessing.Process instead of a mere function, just to be able to save state. For long-running simulations, it would make sense to store jobs and results on disk, rather than in memory, so that the execution of the queue may be resumed after a possible interruption. In that case one may, or may not, find the subprocess module more convenient for starting the external processes. The worker implementation would then be in a separate module that is run as a script.