Solver slow after start of new problem

I have noticed that, after solving a time dependent problem and observing solution time, after going back and either starting a new problem or changing some BC's or other factors, the solver starts out very slow, as if memory is full or something.  If I close FEATool and start over with the new factors, the problem solves as fast as the first run through.  

Is there a way of totally clearing FEATool between solutions, or do I have to close/restart the app to totally clear the memory, or is there something else I'm missing?

All model data should have been cleared when starting a new problem. It could possibly be due to Matlab retaining or reserving data. You maybe could try using the "clear all", and "pack".

If you encounter problems with a specific model then please attach/submit your model file or detailed steps to reproduce the problem so that issues can be reproduced and debugged.

tkdiff wrote

I have noticed that, after solving a time dependent problem and observing solution time, after going back and either starting a new problem or changing some BC's or other factors, the solver starts out very slow, as if memory is full or something.  If I close FEATool and start over with the new factors, the problem solves as fast as the first run through.  

Is there a way of totally clearing FEATool between solutions, or do I have to close/restart the app to totally clear the memory, or is there something else I'm missing?

"clear all" and "pack" executed in Matlab had no effect.  

It is not a special problem.  I am running a standard 1D diffusion problem on the FEAtool GUI app, geom is a line 0.5 long, std grid of 0.025 grid size with 2 refine steps, default equation settings except D = 1e-6, with BC 1 = Concentration with c0 = 1e20, and BC 2 is insulation/symmetry.  Solve settings are time dependent, IC is expression, mumps, and all default settings except time step = 1 and sim time = 200.  When solving, the interations start very quickly, gradually slowing down as it progresses (I assume the matrix gets more populated).  After solving, or if I cancel solving part way through, if I change a couple of settings or start a new problem, the solver starts out as slowly as the last time step through the previous solution, including if I execute clear all or pack in the Matlab window.  The only way I can get the solution to reset and start fast is to close the FEAtool app and restart it.
I am still just working with the trial version to test it out, so I can't try running an m file in Matlab - is that part of the problem?  Is this normal behavior?  Changing any of the variables I mentioned above has no effect, nor does making D dependent on C making it a non linear problem.

Thank you for elaborating on your issue. Assuming I have understood correctly, I believe this to be a combination of the "extreme" magnitude of your expected solution and the effect of an implicit, and in this case unneccesarry, non-linear boundary condition.

For most problems a solution with magnitude over 1e15 usually indicates that something has gone wrong numerically. FEATool does not yet employ any clever internal scaling so starting with a magnitude of 1e20 certainly influences the solution behaviour (the non-linear default solution convergence may not ever be reached with this magnitudes of solution variables, and the sparse solvers might simply not be that effective here).

Secondly FEATool implements the "insulation" boundary condition for the Convection and Diffusion physics mode by simply subtracting the convective part, i.e. "Neumann BC = (nx*u_cd)*c)" so, even if like it seems in your case the convective term is zero (u = 0), the problem will be considered non-linear and not be efficient to solve.

The solution to the first is to manually scale your input data (and manually rescale the result), and to the second is to use the "Convective flux/outflow" boundary condition instead of "Insulation/symmetry" since with zero convective terms they are effectively identical (albeit implemented differently).

Considering your observations of restarts, there could of course be some cached memory issues as well, but I would suggest to try the above first to see if it helps.

tkdiff wrote

"clear all" and "pack" executed in Matlab had no effect.  

It is not a special problem.  I am running a standard 1D diffusion problem on the FEAtool GUI app, geom is a line 0.5 long, std grid of 0.025 grid size with 2 refine steps, default equation settings except D = 1e-6, with BC 1 = Concentration with c0 = 1e20, and BC 2 is insulation/symmetry.  Solve settings are time dependent, IC is expression, mumps, and all default settings except time step = 1 and sim time = 200.  When solving, the interations start very quickly, gradually slowing down as it progresses (I assume the matrix gets more populated).  After solving, or if I cancel solving part way through, if I change a couple of settings or start a new problem, the solver starts out as slowly as the last time step through the previous solution, including if I execute clear all or pack in the Matlab window.  The only way I can get the solution to reset and start fast is to close the FEAtool app and restart it.
I am still just working with the trial version to test it out, so I can't try running an m file in Matlab - is that part of the problem?  Is this normal behavior?  Changing any of the variables I mentioned above has no effect, nor does making D dependent on C making it a non linear problem.

Johan,
Thanks for the response (I just purchased by the way) and I discovered that if I export the solution as an m file, it flies when executed, but the postplot result is a vertical line, instead of the expected distribution.  I need to look at that and find out why it is doing that in Matlab, but looks OK in the FEAtool app.

Perhaps if I explain the physical problem I am addressing:  I am using this 1D solution to solve Fick's law for solid state impurity deposition in silicon wafer.  For deposition, at x=0, surface flux is a constant c0, and outflow at the far boundary is zero.  Solid state diffusion occurs at temp over time.  The linear version of this (Constant D) solves to a distribution based on erf, but behavior at high c is usually non linear with D dependent on c and Temp.  Impurity concentration values are typically in the 1E15 to 1E22 range, especially at the surface, and need to be the realistic value to properly affect D(c).  How would I run the problem using a scaled c but realistic values of c to affect D(c).  D(c) is usually calculated as D0*(factor*c/c0).  I guess I'd have to scale both c and c0.  I also didn't understand the BC 2 issue you mentioned, and that it created a non linear condition - I was trying to achieve flux = 0 at essentially infinity.

Would the Fenics solver work better with the large value c?

I'll try your suggestions and post results.
Tom

I tried scaling the numbers by log10 of the large numbers, and you are correct - convergence was much better - 1 iteration per delta t for linear D, and only 2-3 iterations for a nonlinear D(c).  I'll try with the different BC 2 condition as you suggest, but I still note the gradual slowdown as the solution progresses, and the repeated start slowdown still exists.  Overall solution time is much better though.

Couple things:  To export the entire solution to a Matlab m file, must I run the solution once to do so?  If I enter the solver parameters and just hit OK and then export, the m file ends at "call solver" in the script.  If I run solve then export, the file is complete.

Also, is there a way to modify the postplot in the app?  I was trying to change the Y axis to log10(c) for a realistic plot, and the plot went off scale and the scale didn't adjust.  I'd also like to make the Y axis log and I can't see how to do that.  Any help there would be appreciated.

Tom

tkdiff wrote

I discovered that if I export the solution as an m file, it flies when executed.

Yes, after profiling it seems the perceived slowdown is actually entirely due to updating the terminal output in the GUI (getting slower the more text is in the log window, so restarting FEATool clears this text and again "speeds" up the solution process). Its kind of a "luxury" problem since typically for more complex, and 2D/3D problems the assembly, solve, solution time etc. completely dominates, while in this case the solution time is negligible. Unfortunately Matlab is commonly considered to be slow and inefficient programming environment, which in this case is quite justified. The Matlab GUI toolkit is not very efficient, and there is not much I can do about it. However, Matlab, as all software for that matter, seems become more and more bloated as time goes by, eating up and effectively nullifying increases in computer performance. Although almost all users seem to prefer to use the latest Matlab releases, as discussed in this linked post, I typically use and recommend version 2011b since the GUI and graphics performance is significantly faster and more responsive (I believe the Mathworks introduced the newer but slower HG2 graphics toolkit in 2012a). I would argue that at least with respect to FEATool there are few if any benifits of actually using a recent Matlab version. Alternatively, the solution as you've found is to run the problem as a Matlab script file (although I believe terminal ouput is still the limiting factor here, so can also experiment with supressing output with the solver flag "solvetime( fea, ..., 'fid', [] )" ).

tkdiff wrote

... I guess I'd have to scale both c and c0

Yes, you would have to scale anything that depended on the unit of c. If you for example scaled your dimensions from m to mm, then you would have to scale every coefficient depending on m to mm scale (and reverse for postprocessing).

tkdiff wrote

I also didn't understand the BC 2 issue you mentioned, and that it created a non linear condition - I was trying to achieve flux = 0 at essentially infinity.

For the convection-diffusion physics mode the insulation Neumann BC should look like:

    n * ( -D grad c + uc ) = 0

However, FEATool solves the non-conservative form which means the convective terms are not included in the Neumann BC per default, therefore the effective BC will look like:

    n * ( -D grad c ) = 0 - n*uc

which, even though in your case u=0, depends on c and is therefore nonlinear. So in your case since u=0 you can just use the Convective BC, since this implements exactly:

    n * ( -D grad c ) = 0

When u=0 both BCs are mathematically equivalent, but implementation wise not, although after solving they should yield the same solution, but solving a linear problem is faster than non-linear and is therefore recommended.

tkdiff wrote

Would the Fenics solver work better with the large value c?

I'm actually not sure if FEniCS does any automatic scaling, and there are no built-in time stepping schemes. So you would have to implement that manually. One advantage of FEniCS is automatic differentiation for highly-nonlinear problems (where in FEATool you have to implement the Jacobian for the Newton method, or use fixed-point/Picard iterations as per default).

tkdiff wrote

Couple things:  To export the entire solution to a Matlab m file, must I run the solution once to do so?  If I enter the solver parameters and just hit OK and then export, the m file ends at "call solver" in the script.  If I run solve then export, the file is complete.

FEATool will only log equivalent commands as they are run, that is you have to actually press the "=" solve button for the corresponding solve command to be logged. Changing the solver parameters just stores them in the GUI data struct for later use (when you actually perform a solve function call).

tkdiff wrote

Also, is there a way to modify the postplot in the app?  I was trying to change the Y axis to log10(c) for a realistic plot, and the plot went off scale and the scale didn't adjust.  I'd also like to make the Y axis log and I can't see how to do that.  Any help there would be appreciated.

You can't really change the axis in the GUI, but you can evaluate and plot an expression such as "log(c)", "exp(c)" etc. directly in the GUI, or you could export your solution to Matlab and use the usual "semilogx", "loglog", etc. plot commands.

Thanks for the detailed answers!

Maybe you could consider, in a future FEAtool release, to provide an option in the GUI for non verbose terminal output, or just a completion summary, or even a progress bar in lieu of the lengthy output, to minimize the effect the window text updates have on time of execution of the calculations.
Also, I'm running Matlab 2019b, and the same iteration progress is reported in the terminal window when I run the m script of the FEAtool file, and progress is much quicker than the GUI for the same problem, even after restarting, and doesn't perceptibly slow over time.
Something perhaps to consider?  My path now would be to develop the problem solution in the GUI, and do repeat runs using the m file for speed.

By the way, is there a reason why the postplot function displays the result graph differently in the Matlab figure window when the m file is executed than it does in the GUI window?  For my diffusion problem, I get a linear plot for x=0 to 1 as desired, but the m file in Marlab gives a plot for x=-5 to 5, so resolution suffers.  There doesn't seem to be a postplot variable to modify this behavior.  I'm looking into Matlab plot methods to get what I want.

Thank you for the increased speed of execution in the latest 1.12.0 release, for re-solving the loaded problem.  There is no longer a slow down in problem execution.  However, I do notice that, after the first solver run, the command log window shows the end of solver statistics, but after a second run of the solver,  doesn't show the final solution statistics - it gets cut off a few lines before the last set of information.  This only happens in the app, not when running the m file in Matlab.

By the way, when installing the new version, I observed that i had to uninstall the current version (earlier build of 1.12), delete the folder, then install the new one.  Otherwise, a second directory was installed with the new version, and Matlab didn't know which one to use.  Is this as it should be, or did I do something wrong?

tkdiff wrote

Thank you for the increased speed of execution in the latest 1.12.0 release, for re-solving the loaded problem.  There is no longer a slow down in problem execution.  However, I do notice that, after the first solver run, the command log window shows the end of solver statistics, but after a second run of the solver,  doesn't show the final solution statistics - it gets cut off a few lines before the last set of information.  This only happens in the app, not when running the m file in Matlab.

A cache functionality to only output every .x seconds has been implemented in v1.12, however didn't take into account that some the last output might not be written (for most simulations where time steps take longer than .x seconds this will not be an issue). So if you are missing output it is in the cache and will be displayed the next something is written to the output window. Some functionality to flush the cache after certain evens such as solving will be added to an updated version later.

tkdiff wrote

By the way, when installing the new version, I observed that i had to uninstall the current version (earlier build of 1.12), delete the folder, then install the new one.  Otherwise, a second directory was installed with the new version, and Matlab didn't know which one to use.  Is this as it should be, or did I do something wrong?

There is a unique 'id' for each app so Matlab should be able to update individual without confusing the apps. However, this might depend on the Matlab version and implementation, thus the safest is perhaps to uninstall and the re-install when updating an app. Alternatively, you can just unzip and put each version in its own directory (if you want to keep older versions) and  then in Matlab just change to the directory with "cd path_to_featool_v1xx", and call "featool" to start (its what the app does when you click on the icon).