Note: This discussion is about an older version of the COMSOL Multiphysics® software. The information provided may be out of date.

Discussion Closed This discussion was created more than 6 months ago and has been closed. To start a new discussion with a link back to this one, click here.

Why does my parametric sweep slow down?

Please login with a confirmed email address before reporting spam

When doing nested parametric sweeps, they start off fast but slow down to a crawl eventually. What am I doing wrong here? Is there a faster way of doing this? Seems it has little to do with my computer memory, which is a lot.

Thanks!
Chris

8 Replies Last Post Oct 25, 2012, 10:21 a.m. EDT
Nagi Elabbasi Facebook Reality Labs

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 20, 2012, 8:34 p.m. EDT
Hi Chris,

In general nested parametric sweeps do not slow down. It is more likely that certain parameter values take longer to solve even if you try them manually (without a parametric sweep). If you provide more info about your model someone on the Forum may provide more specific feedback. Here are two factors that can cause this solver slowdown: (i) if the parameter sweeps involve geometry changes that increases the number of degrees of freedom, or (ii) if the parameter sweeps result in a more nonlinear problem that is harder to converge. Two examples of the second factor are higher loads in a structural analysis involving nonlinear materials, and higher velocities in fluid flow that trigger turbulence.

Nagi Elabbasi
Veryst Engineering
Hi Chris, In general nested parametric sweeps do not slow down. It is more likely that certain parameter values take longer to solve even if you try them manually (without a parametric sweep). If you provide more info about your model someone on the Forum may provide more specific feedback. Here are two factors that can cause this solver slowdown: (i) if the parameter sweeps involve geometry changes that increases the number of degrees of freedom, or (ii) if the parameter sweeps result in a more nonlinear problem that is harder to converge. Two examples of the second factor are higher loads in a structural analysis involving nonlinear materials, and higher velocities in fluid flow that trigger turbulence. Nagi Elabbasi Veryst Engineering

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 20, 2012, 9:53 p.m. EDT
Hi, thanks for your reply.

I am doing a 2D wave number sweep for an eigenfrequency problem in structural mode. Each sweep should take the same amount of time, there is no reason why one value of the wave number should take longer than another. Plus I've check that by running them individually and they solve fast like the ones early in the parametric sweep. Additionally, there is clearly a 'ramping' up of the solve time as the number of solutions increases. Nothing nonlinear and no geometry changes. Not sure why this happening, but it also happens when I run the model from Matlab using a 'for' loop instead of the built in COMSOL parametric sweep functions.

~Chris





Hi Chris,

In general nested parametric sweeps do not slow down. It is more likely that certain parameter values take longer to solve even if you try them manually (without a parametric sweep). If you provide more info about your model someone on the Forum may provide more specific feedback. Here are two factors that can cause this solver slowdown: (i) if the parameter sweeps involve geometry changes that increases the number of degrees of freedom, or (ii) if the parameter sweeps result in a more nonlinear problem that is harder to converge. Two examples of the second factor are higher loads in a structural analysis involving nonlinear materials, and higher velocities in fluid flow that trigger turbulence.

Nagi Elabbasi
Veryst Engineering


Hi, thanks for your reply. I am doing a 2D wave number sweep for an eigenfrequency problem in structural mode. Each sweep should take the same amount of time, there is no reason why one value of the wave number should take longer than another. Plus I've check that by running them individually and they solve fast like the ones early in the parametric sweep. Additionally, there is clearly a 'ramping' up of the solve time as the number of solutions increases. Nothing nonlinear and no geometry changes. Not sure why this happening, but it also happens when I run the model from Matlab using a 'for' loop instead of the built in COMSOL parametric sweep functions. ~Chris [QUOTE] Hi Chris, In general nested parametric sweeps do not slow down. It is more likely that certain parameter values take longer to solve even if you try them manually (without a parametric sweep). If you provide more info about your model someone on the Forum may provide more specific feedback. Here are two factors that can cause this solver slowdown: (i) if the parameter sweeps involve geometry changes that increases the number of degrees of freedom, or (ii) if the parameter sweeps result in a more nonlinear problem that is harder to converge. Two examples of the second factor are higher loads in a structural analysis involving nonlinear materials, and higher velocities in fluid flow that trigger turbulence. Nagi Elabbasi Veryst Engineering [/QUOTE]

Nagi Elabbasi Facebook Reality Labs

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 21, 2012, 12:42 p.m. EDT
That is strange. I suggest sending this problem to COMSOL Support.
That is strange. I suggest sending this problem to COMSOL Support.

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 22, 2012, 12:41 p.m. EDT
I have come up with a work around for, in case others have this issue.


This is for a 2D sweep.
First run the script from Matlab, using 'for' loops instead of COMOSL's built in parametric sweep commands. Put one loop at the top of the code, and the other as far down as possible (i.e. past the mesh, assuming you don't need to re-mesh every time). The top loop some how clears out the issue, and although I have to re-meash for the top loop, it vastly improves the time as compared to doing everything from the COMSOL GUI.

anyway works for me.


~Chris
I have come up with a work around for, in case others have this issue. This is for a 2D sweep. First run the script from Matlab, using 'for' loops instead of COMOSL's built in parametric sweep commands. Put one loop at the top of the code, and the other as far down as possible (i.e. past the mesh, assuming you don't need to re-mesh every time). The top loop some how clears out the issue, and although I have to re-meash for the top loop, it vastly improves the time as compared to doing everything from the COMSOL GUI. anyway works for me. ~Chris

Nagi Elabbasi Facebook Reality Labs

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 24, 2012, 12:16 a.m. EDT
Chris, thanks for sharing the workaround.
Chris, thanks for sharing the workaround.

Ivar KJELBERG COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 24, 2012, 12:57 a.m. EDT
Hi

I have noticed some changes in the handling of multiple parametric sweeps in latest 4.3a:

1) first you have now the "specific combination" ((A1 B1) (A2 B2) (A3 B3)) and the "All combination" ((A1 B1) (A1 B2) (A1 B3) (A2 B1) (A2 B2) ...) options and more recently the "Study extension" tab (Automatic / Off). This last option controls how a parametric sweep is included, either as an external loop running around the full model geoemtry, mesh physics study initialising to "0" default initial cases, and the "study continuation" (if possible) looping only the study and using each solver run to as initial conditions and starting point for the next run, hence speeding up strongly the convergence (in most cases). => a Parametric sweep node can be interpreted as a continuation case "automatically" by COMSOL, and I do not know how we user can identify it, I got burned recently, I did want to force an external loop and COMSOL automatically an internal one, then I discovered the "off" button, that fixed it ;)

Remains to check how is a multiple study initiated, all from "0" for the first parameter and as continuation for the 2nd (if possible) ? or all cases from the previous step or some mix ?).

These kind of behaviour could give long conversion for given combinations of parameters, and then shorter for a series

My conclusions, a more verbose logging option would be nice, today there are 2 levels but I do not get much more from "detailed" I would love to have more

--
Good luck
Ivar
Hi I have noticed some changes in the handling of multiple parametric sweeps in latest 4.3a: 1) first you have now the "specific combination" ((A1 B1) (A2 B2) (A3 B3)) and the "All combination" ((A1 B1) (A1 B2) (A1 B3) (A2 B1) (A2 B2) ...) options and more recently the "Study extension" tab (Automatic / Off). This last option controls how a parametric sweep is included, either as an external loop running around the full model geoemtry, mesh physics study initialising to "0" default initial cases, and the "study continuation" (if possible) looping only the study and using each solver run to as initial conditions and starting point for the next run, hence speeding up strongly the convergence (in most cases). => a Parametric sweep node can be interpreted as a continuation case "automatically" by COMSOL, and I do not know how we user can identify it, I got burned recently, I did want to force an external loop and COMSOL automatically an internal one, then I discovered the "off" button, that fixed it ;) Remains to check how is a multiple study initiated, all from "0" for the first parameter and as continuation for the 2nd (if possible) ? or all cases from the previous step or some mix ?). These kind of behaviour could give long conversion for given combinations of parameters, and then shorter for a series My conclusions, a more verbose logging option would be nice, today there are 2 levels but I do not get much more from "detailed" I would love to have more -- Good luck Ivar

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 25, 2012, 10:14 a.m. EDT

When doing nested parametric sweeps, [...] Seems it has little to do with my computer memory, which is a lot.

Thanks!
Chris


Hi Chris,

I've had a similar problem, but on 4.2 (I do not have 4.3 for now) : nested parametric sweeps apparently stopping after some parametric iterations. Looking at CPU usage (and listening to the laptop fan...), it looked like COMSOL was doing nothing, waiting forever... It was a linear acoustic problem thus, as for you, no reason to suspect a nonlinear difficulty for some parameter set.

I suspected a memory problem, and indeed, I noticed that when quitting some memory consuming program running at the same time (typically Firefox), the parametric sweep immediately recovered a normal speed (and the fan started again...).
I've checked that several times (on MacOsX) and a collegue had the same phenomenon under Linux.

That may sound a bit esoteric, but it's real...I guess it has something to do with the manner COMSOL handles memory... I had only 4 Go at that time, so the problem you have may be different.

Hope this helps




[QUOTE] When doing nested parametric sweeps, [...] Seems it has little to do with my computer memory, which is a lot. Thanks! Chris [/QUOTE] Hi Chris, I've had a similar problem, but on 4.2 (I do not have 4.3 for now) : nested parametric sweeps apparently stopping after some parametric iterations. Looking at CPU usage (and listening to the laptop fan...), it looked like COMSOL was doing nothing, waiting forever... It was a linear acoustic problem thus, as for you, no reason to suspect a nonlinear difficulty for some parameter set. I suspected a memory problem, and indeed, I noticed that when quitting some memory consuming program running at the same time (typically Firefox), the parametric sweep immediately recovered a normal speed (and the fan started again...). I've checked that several times (on MacOsX) and a collegue had the same phenomenon under Linux. That may sound a bit esoteric, but it's real...I guess it has something to do with the manner COMSOL handles memory... I had only 4 Go at that time, so the problem you have may be different. Hope this helps

Ivar KJELBERG COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago Oct 25, 2012, 10:21 a.m. EDT
Hi

I have noticed the same on Windows (but not limited to Parametric sweeps, just large models going over RAM limit).

My conclusions was that MS Win-7 (even 64) and swapping is not compatible and/or not handled correctly (long delays CPU at 2% occupation, system frosen ... fan off ;(.
But as I do not have any UX running and installed I could check if it worked better, this was 4.3 and 4.3a recently.

Workaround: keep within available RAM, kill any not necessary MS-Win7 add on, then everything is OK. Could it be that multiple sweep runs out of RAM ? wanst there a store intermediate to file somewhere before in v3.5a ? Still there today ? I havnt checked that one.

--
Good luck
Ivar
Hi I have noticed the same on Windows (but not limited to Parametric sweeps, just large models going over RAM limit). My conclusions was that MS Win-7 (even 64) and swapping is not compatible and/or not handled correctly (long delays CPU at 2% occupation, system frosen ... fan off ;(. But as I do not have any UX running and installed I could check if it worked better, this was 4.3 and 4.3a recently. Workaround: keep within available RAM, kill any not necessary MS-Win7 add on, then everything is OK. Could it be that multiple sweep runs out of RAM ? wanst there a store intermediate to file somewhere before in v3.5a ? Still there today ? I havnt checked that one. -- Good luck Ivar

Note that while COMSOL employees may participate in the discussion forum, COMSOL® software users who are on-subscription should submit their questions via the Support Center for a more comprehensive response from the Technical Support team.