General recommendations for speeding up solve time

I'm working on a relatively large heat transfer problem. Large grid, lots of boundaries, custom function for heat power, small step size. These are all things that make the simulation take a very long time time to run.

I notice that there are some solve time statistics:

  t-asm_m :                                                                                                
 t-asm_a :                                                                                                    
 t-asm_f :                                                                                                  
 t-bdr   :                                                                                                  
 t-lc_mv :                                                                                                    
 t-sol   :                                                                                                
 t-tot   :                                                                                              

but I don't really know how to interpret them. For example if t-asm_f is taking most of the time what is the best way to reduce it? Descriptions for the abbreviations would be helpful and just a quick suggestion to reduce each time would be greatly appreciated.

I understand that a large grid size will obviously take more time to solve, but what about the number of boundaries? Is that a one time computation, or is it something that effects what is calculated every time step? Cylinders default to having 6 possible boundary surfaces. Would it help if the four different sections along the circumference where merged into one? Obviously that would limit possible problem definitions, but is that even possible/ would it even help speed things up?

Clearly any custom function added to any of the equation parameters will have a large impact on solve time. My function only returns a nonzero answer if the cell is above 130C. Is there anyway to avoid the function call unless a condition is met? Would that be any faster then just having the function check the max temperature? Similarly are there other options for stopping the simulation? I would love to stop the sim if the max temperature of certain subdomains are above 130C. I could then change the setup to include the function call.

I noticed that with my materials if the step size is too large the temperatures will oscillate back and forth. I'm guessing there is not much I can do about that.

I understand this is a super long and not very detailed post/ list of questions. I greatly appreciate any amount of help you are able to provide.

The solver-timing meanings/abbreviations are as follows:

 t-asm_m : assembly of mass matrix                                                                                                
 t-asm_a : assembly of bi-linear forms/stiffness matrix                                                                                                   
 t-asm_f : assembly of linear forms/right hand side/load vector                                                                                                  
 t-bdr   : implementing boundary conditions                                                                                                 
 t-lc_mv : linear combinations/matrix-vector products                                                                                                   
 t-sol   : linear solver                                                                                               
 t-tot   : total time

It is of course completely problem specific how much time it will take to solve a model. In general the more non-linear the problem is the more time it will take as coefficients and matrices will frequently have to be re-evaluated and re-assembled which is costly. If you are using "custom functions" as coefficients you might be able to save some computations by caching results (using the "persistent" variable in your Matlab scripts for the custom functions). Unless you model has an extreme amount of boundaries it would be unusual that the number would affect the solution speed significantly (but if you want to try you can manually set the boundary numbers in the "fea.grid.b(3,:)" field, see https://www.featool.com/doc/grid.html#grid_fmt for reference).

Ok thank you for the help. Do you have any idea how I could stop the simulation if any temperature in a list of subdomains exceeds a constant value?

mgriffith wrote

Do you have any idea how I could stop the simulation if any temperature in a list of subdomains exceeds a constant value?

Unfortunately, that is not a feature that is implemented yet. You could possibly monitor it with a custom coefficient function that returns zero, but not stop the solution process.

wait. If I wrote a custom function couldn't I pretty much do whatever I wanted. I could put a breakpoint inside the stop condition I was interested in and then manually click the stop button. I'm also guessing there is some callback that gets ran when the user clicks the stop button could I just call that directly? Sorry for the back and forth, I'm just bored waiting for gmsh :)

Yes, good point, I didn't consider that workaround. Something like this snippet should be sufficient to programatically trigger the Cancel button the waitbar dialog.

  h_btn_cancel = findall(findall(0, 'Tag', 'fea_GuiWaitbar'), 'String', 'Cancel');
  cbf = get(h_btn_cancel, 'Callback');
  cbf(h_btn_cancel)

Note, that if you write a equation coefficient function of the type:

  function [ out ] = myfuncoef(T)
    if( max(T)>100 )
      % Do something
    end

    out = zeros(size(T));

And use it as an equation coefficient it might be called/evaluated several times in each assembly step (assembly is performed on vectorized blocks of cells to conserve memory). So you might for example also pass in coordinates "x,y,z" or time "t" to define some tests whether a new solver iteration has started. For example:

  function [ out ] = myfuncoef(T, t)
    persistent T_max t_old
    if( ~isequal(t, t_old) )
      T_max = -inf;
    else
      T_max = max([T_max;T(:)]);
    end

    if( ~isempty(t_old) && T_max>100 )
      % Do something
    end

    t_old = t;
    out = zeros(size(T));

Precise Simulation wrote

Yes, good point, I didn't consider that workaround. Something like this snippet should be sufficient to programatically trigger the Cancel button the waitbar dialog.

  h_btn_cancel = findall(findall(0, 'Tag', 'fea_GuiWaitbar'), 'String', 'Cancel');
  cbf = get(h_btn_cancel, 'Callback');
  cbf(h_btn_cancel)

Just to be sure I am not missing something ... I assume this method can not be used to stop mumps or one of the other linear solvers, which I understood can not be stopped and must run to completion (success or failure)....

Correct?

OR does this mean that if I execute the linear solver script from the MATLAB script editor, then I can interrupt execution as if I were stopping it in the debugger?

Kind regards,
-Randal

No, the state of the waitbar Cancel button has only explicity been programmed to be read and checked at certain points in the 'solvestat', 'solvetime', 'solveeig', 'fsisolve', and 'gridgen' functions.

The linear solver libraries in contrast do not include functionality for checking gui states, and moreover the single threaded way Matlab currently works would most likely not even read/detect changed gui states until a library function call has finished and exited.