Comsol-Matlab tutorial

Below is a guide to using the Comsol-Matlab interface to run models. It is compiled purely from my own work and is based largely on the results of extensive trial and error. Hopefully there are some helpful hints, I thoroughly recommend reading the memory issue section if you intend to do multiple runs of a model.

Setting up the software

The first step is installing the correct software. You will require a licensed copy of Comsol 3.5a, and a licensed copy of Matlab 2007. Both of these can be installed from the VPM repo.

A Comsol-Matlab (CM) interface is initialised by running the command comsol_35a matlab. This should start a java instance of Matlab 2007 with Comsol commands enabled. To check the link try the command flclear fem which will not work in a standard Matlab instance.

Within the CM interface all Matlab functionality is unchanged. In addition to this a new set of Comsol commands are available, all of which are documented and have standard help functionality.

Building a model

There is no particular correct way to build your model in a CM interface, it is not all that intuitive. Personally, I have found that the best way to work with and build models is within a standard Comsol session. Once built a model can easily be manipulated within the CM interface. The internal language used by Comsol is fully compatible with Matlab script, and as you build a model Comsol saves the commands in a Matlab usable format in a file named myModel_history.m. I have uploaded an example script here File:JcModel history.txt.

Building your initial script

The history file is generally split into three parts; setting up the model, running the model, and post-processing and plotting. If your model has been tweaked, run and saved multiple times then the history file can become quite convoluted and there will be multiple instances of these three parts. Since this file is written chronologically, the most up-to-date version of your model will be at the end and this is the part that should be copied into a new script.

There are several actions that must be in your script to define the model, most of which will be pulled directly from the history script;

• The Comsol version blurb, at the very start of the history script.
• The description of the Geometry, also found at the start of the script. This commands for the geometry are not reissued each time you run the model unless changed. You may have to scroll through the model to find the most recent version of the geometry description. This must be followed by the Analysed geometry commands.
• A Constants section is next followed by an Application mode section. Both of these describe the mode in which Comsol runs and the constants it uses.
• Various Boundary and Subdomain settings and equations which describe the variables to be kept track of, and any input (heat, pressure etc) to the model along its boundaries or surfaces.
• A Library materials section which is completely optional.
• A few model initialisation commands.
• A mesh initialisation command.
• A 'run the model' command.
• Post-processing commands.

Adding variables

One of the main benefits of using the CM interface is the ability to setup automated changes of model variables. This removes the tedious and repetitive need to perform this operation in a Comsol window.

The CM interface allows standard Matlab commands and variables to be used. Thus, when defining a model, it is straightforward to replace a hard-coded value with a variable. In the uploaded example script, the line

equ.D = {{1.6360e11,0.9230e11,0.6792e11,0,0,0;0.9230e11, ...    
1.6360e11,0.6792e11,0,0,0;0.6792e11,0.6792e11,1.8520e11, ...    
0,0,0;0,0,0,0.3565e11,0,0;0,0,0,0,0.4705e11, ...        
0;0,0,0,0,0,0.4705e11}};

is replaced with

equ.D = elac_const; 

where elac_const is a 6x6 matrix of elastic constants which is altered for each iteration of the model. Note that the elac_const variable must be in the same format as what it is replacing, i.e. a 6x6 cell within a 1x1 cell. Different variables are stored in different ways.

Exporting results

Once the model has been run the solution is saved to a fem.sol structure and can be manipulated. There are multiple ways and commands to do this. A few of the most useful commands are:

• postinterp for interpolating results onto a regular grid,
• posteval for evaluating a solution at a particular point/surface/boundary,
• postplot for plotting.

All of these commands have reasonable documentation. These commands can be used to save the solution to a variable which is easily saved as a .mat file.

Memory issues

The CM interface has a particularly irritating problem with memory leakage. If a single model run is performed then there is no problem, however for multiple iterations the previous model is not properly cleared from memory. Thus each iteration fills the memory further until you end up in swap. I have not found a solution to this problem, and only have a work around. Instead of altering a variable and running the model within a for-loop, instead a model can be run in CM batch mode.

Essentially two scripts are required; a subscript which runs with the CM interface and does all the model related things, and a main script to call the subscript. The main script is called once and run in a standard Matlab 2011 window. All the main script does is:

• save all of the changing variables to a reference .mat file,
• launch CM to run the model code in batch mode,
• the CM script then loads the reference .mat file and uses the variables saved in it to run the model once, the CM script then exits back to the 2011 Matlab window,
• the main script then loops to the next iteration of the model, with a new set of variables and we start from step one.

This is not the prettiest solution, but does work well. The code required to run CM in batch mode is;

 !comsol_35a matlab -np 4 -ml -nodesktop -ml -nosplash -mlr "SubscriptFile, exit"

The 4 is replaced by however many cores there are available to run the model, and SubscriptFile is replaced by the name of the subscript without the .m extension.

Feel free to email me with any questions Jethro 15:51, 7 January 2013 (GMT)