There are some new developments related to optimization, parameter scanning and beyond, of multiple Elmer simulations in "devel" branch. This involves new section ”Run Control”. This is a special section in the way that it is analyzed before the rest of the simulation is carried out.
For example, test case "ParamFourHeaters" has the following section that will run the case four times altering the parameters as defined in ascii table par.dat
Code: Select all
Run Control
Run Control Iterations = Integer 4
! give parameters as an ascii matrix:
Parameter File = File "par.dat"
Parameter Count = Integer 4 ! columns in matrix
Parameter Row Offset = Integer 2 ! starts from line 3
End
Code: Select all
Body Force 1
Name = "Heater1"
Heat Source = $rpar(0)
End
The parameters may also be generated by internal optimization procedures. The routines in the old FindOptimum solver has been copy-pasted & slightly modified to provide simple internal optimization routines. For example, in test case "OptimizeSimplexFourHeatersInt" we have:
Code: Select all
Run Control
Run Control Iterations = Integer 100
Parameter Count = Integer 4
Parameter Optimal Finish = Logical True
Parameter Best File = File "optimize-best.dat"
Parameter History File = File "optimize-history.dat"
Cost Function = Variable Time
Real Procedure "CostFunction" "CostFunction"
Optimization Method = String "simplex"
Simplex Relative Length Scale = Real 1.0
End
Traditionally Elmer has had time dependency mode "scanning" that has enabled simple sweeps over parameters. This can now be achieved also with the new "Run Control". Test case "HelmholtzPlaneWavesParam" demonstrates how to scan over frequency space. The key line is
Code: Select all
Frequency = Variable "run"
Real MATC "1000*tx"
So why did the old "scanning" mode not do the work? It perhaps could have done it for steady state cases. The problem is that it used the time as a pseudo variable which meant that it was impossible to study transient systems. This can deal with transient cases (the initialization may need to be checked).
So why now do everything externally? That might be the ideal modular way to work. However, there may be additional features that you can do when everything is internal also concerning the history. Also some redundant pre and post tasks are eliminated. There is no strong case for this but with this rather modest work, why not have an internal option?
An example of something more non-conventional use of "Run Control" is found in test case "RunControlStructured". There
a simple 3D heat equation is solved and the boundary conditions between different runs are inherited from
the other end of the cube.
We are open for comments & ideas. Do you have any idea how this additional outer control level could be used?
-Peter