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.

Time Stepping Taking Too Long on laptop

Please login with a confirmed email address before reporting spam

Hi,

I'm running a 2D model on comsol and it taking too long compute. I used time step of range(0,0.1,0.5). I have attacched the mph file


9 Replies Last Post Jul 15, 2023, 1:51 p.m. EDT
Dave Greve Certified Consultant

Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 10, 2023, 10:36 a.m. EDT

I have attacched the mph file

Except you didn't. Try it again.

> I have attacched the mph file Except you didn't. Try it again.

Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 10, 2023, 12:50 p.m. EDT
Updated: 10 months ago Jul 10, 2023, 1:12 p.m. EDT

I have attacched the mph file

Except you didn't. Try it again.

Sorry, here is it

>> I have attacched the mph file > >Except you didn't. Try it again. Sorry, here is it


Jim Freels mechanical side of nuclear engineering, multiphysics analysis, COMSOL specialist

Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 10, 2023, 3:45 p.m. EDT

Without any knowledge of the problem statement, and just looking at your model file, I see several inconsistencies that you may want to address to get at the cause of the problem.

  1. Your units are declared as SI, therefore, you should specify units for all your parameters. For example, the parameters d and w I assume are units of length (m). It appears that the geometry is in the right units by default. But perhaps other parts of your model are not.
  2. Specifically, everywhere you see the type shown in orange color, the code is shown a corresponding error message with units error.
  3. You are using the default mesh with an extremely fine mesh. This causes the solver to have nearly a million degrees of freedom. Hence, the very first time step appears to loop forever. Suggest changing this to much smaller mesh and obtain a coarse solution first; especially to debug your model. I did so, and it failed quickly that an inconsistent initial condition and could not establish an initial condition. I suspect this is related to your orange errors and inconsistent units.

Please send a corrected model file if you continue to get stuck.

-------------------
James D. Freels, Ph.D., P.E.
Without any knowledge of the problem statement, and just looking at your model file, I see several inconsistencies that you may want to address to get at the cause of the problem. 1. Your units are declared as SI, therefore, you should specify units for all your parameters. For example, the parameters d and w I assume are units of length (m). It appears that the geometry is in the right units by default. But perhaps other parts of your model are not. 2. Specifically, everywhere you see the type shown in orange color, the code is shown a corresponding error message with units error. 3. You are using the default mesh with an extremely fine mesh. This causes the solver to have nearly a million degrees of freedom. Hence, the very first time step appears to loop forever. Suggest changing this to much smaller mesh and obtain a coarse solution first; especially to debug your model. I did so, and it failed quickly that an inconsistent initial condition and could not establish an initial condition. I suspect this is related to your orange errors and inconsistent units. Please send a corrected model file if you continue to get stuck.

Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 10, 2023, 4:04 p.m. EDT

Without any knowledge of the problem statement, and just looking at your model file, I see several inconsistencies that you may want to address to get at the cause of the problem.

  1. Your units are declared as SI, therefore, you should specify units for all your parameters. For example, the parameters d and w I assume are units of length (m). It appears that the geometry is in the right units by default. But perhaps other parts of your model are not.
  2. Specifically, everywhere you see the type shown in orange color, the code is shown a corresponding error message with units error.
  3. You are using the default mesh with an extremely fine mesh. This causes the solver to have nearly a million degrees of freedom. Hence, the very first time step appears to loop forever. Suggest changing this to much smaller mesh and obtain a coarse solution first; especially to debug your model. I did so, and it failed quickly that an inconsistent initial condition and could not establish an initial condition. I suspect this is related to your orange errors and inconsistent units.

Please send a corrected model file if you continue to get stuck. Okay, thank you so much

>Without any knowledge of the problem statement, and just looking at your model file, I see several inconsistencies that you may want to address to get at the cause of the problem. > >1. Your units are declared as SI, therefore, you should specify units for all your parameters. For example, the parameters d and w I assume are units of length (m). It appears that the geometry is in the right units by default. But perhaps other parts of your model are not. >2. Specifically, everywhere you see the type shown in orange color, the code is shown a corresponding error message with units error. >3. You are using the default mesh with an extremely fine mesh. This causes the solver to have nearly a million degrees of freedom. Hence, the very first time step appears to loop forever. Suggest changing this to much smaller mesh and obtain a coarse solution first; especially to debug your model. I did so, and it failed quickly that an inconsistent initial condition and could not establish an initial condition. I suspect this is related to your orange errors and inconsistent units. > >Please send a corrected model file if you continue to get stuck. Okay, thank you so much

Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 10, 2023, 7:59 p.m. EDT

Hi James,

I was able to check the unit. but I still have issue with my model. I'm using a pi/2 as the BC at the middle of the an rectangular channel and zero everywhere else for the theta and no slip BC for the u and v. For the initial also choose an initial condition that match the BC but I still received an error of** inconsistence initial conditions**. I have tried all the possible suggestions but couldn't work.

I have attached the mph file

Hi James, I was able to check the unit. but I still have issue with my model. I'm using a pi/2 as the BC at the middle of the an rectangular channel and zero everywhere else for the theta and no slip BC for the u and v. For the initial also choose an initial condition that match the BC but I still received an error of** inconsistence initial conditions**. I have tried all the possible suggestions but couldn't work. I have attached the mph file


Jim Freels mechanical side of nuclear engineering, multiphysics analysis, COMSOL specialist

Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 11, 2023, 9:25 a.m. EDT

Hello Ijuptil Joseph,

I have attached a modified model file where I have made some changed and performed some debugging. What I have done is included as comments in the model description at the root level. I have proven (to myself anyway) that the model has an instability caused by the coupling term for volume force between the PDE and the creeping flow physics. This term is very complex, and I don't have time to get into it deeply to determine what is the source of the term and if it is code up right. I will leave that to you.

Also, I suggest you refer to the application library and examine how others have used the microfluids physics module to model their applications. I noticed you had no pressure boundary, no inlet/outlet boundary, or no open boundary; i.e., the flow was completely enclosed. I added an open boundary out of necessity to get the flow equations to solve. If you want to keep the geometry enclosed from fluid flow, then you need at least a pressure Dirichlet constraint somewhere. Suggest looking at the classic cavity problem for an example of that (also in the application library).

One way to help in debugging your volume-force coupling issue is the gradually increase the size of the force until it reaches the desired magnitude. Perhaps that is what you were doing with the parametric sweep.

You have an interesting problem, and I would like to work on it more, but no time right now. Please post back here when you get it solved and running so we know what you did.

Regards.

-------------------
James D. Freels, Ph.D., P.E.
Hello Ijuptil Joseph, I have attached a modified model file where I have made some changed and performed some debugging. What I have done is included as comments in the model description at the root level. I have proven (to myself anyway) that the model has an instability caused by the coupling term for volume force between the PDE and the creeping flow physics. This term is very complex, and I don't have time to get into it deeply to determine what is the source of the term and if it is code up right. I will leave that to you. Also, I suggest you refer to the application library and examine how others have used the microfluids physics module to model their applications. I noticed you had no pressure boundary, no inlet/outlet boundary, or no open boundary; i.e., the flow was completely enclosed. I added an open boundary out of necessity to get the flow equations to solve. If you want to keep the geometry enclosed from fluid flow, then you need at least a pressure Dirichlet constraint somewhere. Suggest looking at the classic cavity problem for an example of that (also in the application library). One way to help in debugging your volume-force coupling issue is the gradually increase the size of the force until it reaches the desired magnitude. Perhaps that is what you were doing with the parametric sweep. You have an interesting problem, and I would like to work on it more, but no time right now. Please post back here when you get it solved and running so we know what you did. Regards.


Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 11, 2023, 6:38 p.m. EDT

Hi James, thank so much. I will definitely post it when I finally get it running.

Hi James, thank so much. I will definitely post it when I finally get it running.

Amin Kazemi Postdoctoral Researcher, University of Toronto

Please login with a confirmed email address before reporting spam

Posted: 10 months ago Jul 12, 2023, 12:00 p.m. EDT
Updated: 10 months ago Jul 12, 2023, 12:27 p.m. EDT

Hi both, I agree with Jim that you don't need that amount of mesh and also you need to define the pressure somewhere in your system (i.e. pressure point constraint). Also agree that your model is highly non-linear and that makes a problem. My recommendations are:

1- Reduce the number of meshes in the bulk, but use small meshes at the two points at the upper boundary where the flow is disturbed.

2- introduce your volume forces gradually to the set of equations: gx = (x-component of the volume force) * step1(t[1/s]), and gy = (y-component of the volume force) * step1(t[1/s])

3- I also noticed that the frequency of the sinusoidal force that makes a change in the flow is too high. In this case, you have to select your time steps small enough to be able to capture the sinusoidal variation in the volume force, and hence the velocity field.

I hope these help.

Amin

Hi both, I agree with Jim that you don't need that amount of mesh and also you need to define the pressure somewhere in your system (i.e. pressure point constraint). Also agree that your model is highly non-linear and that makes a problem. My recommendations are: 1- Reduce the number of meshes in the bulk, but use small meshes at the two points at the upper boundary where the flow is disturbed. 2- introduce your volume forces gradually to the set of equations: gx = (x-component of the volume force) * step1(t[1/s]), and gy = (y-component of the volume force) * step1(t[1/s]) 3- I also noticed that the frequency of the sinusoidal force that makes a change in the flow is too high. In this case, you have to select your time steps small enough to be able to capture the sinusoidal variation in the volume force, and hence the velocity field. I hope these help. Amin

Please login with a confirmed email address before reporting spam

Posted: 9 months ago Jul 15, 2023, 1:51 p.m. EDT

Thank you Amin. T will cehck this

Thank you Amin. T will cehck this

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.