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.
Model couplings: Integration vs. Summation over nodes
Posted 10 apr 2013, 04:38 GMT-4 General, Modeling Tools & Definitions, Parameters, Variables, & Functions, Structural Mechanics Version 4.3a 15 Replies
Please login with a confirmed email address before reporting spam
Hello,
I am working with two modules Structural Mechanics and general form PDE as coupled. I need a model coupling to define an integration. When I choose "Summation over nodes", my model works fine, converges and gives logical results except the fact that it calculates my volume incorrectly, which I think is related to the mesh. When I select "Integration", I see that my model calculates my volume correctly as the initial value; however, my model hits the maximum memory and gives "out of memory" error. I use this integration operator inside the PDE and there are terms like Elastic modulus, strain energy and DiracDelta function inside the operator.
Could any body have a suggestion for me?
Thank you in advance.
Onur
I am working with two modules Structural Mechanics and general form PDE as coupled. I need a model coupling to define an integration. When I choose "Summation over nodes", my model works fine, converges and gives logical results except the fact that it calculates my volume incorrectly, which I think is related to the mesh. When I select "Integration", I see that my model calculates my volume correctly as the initial value; however, my model hits the maximum memory and gives "out of memory" error. I use this integration operator inside the PDE and there are terms like Elastic modulus, strain energy and DiracDelta function inside the operator.
Could any body have a suggestion for me?
Thank you in advance.
Onur
15 Replies Last Post 19 apr 2013, 09:55 GMT-4
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
The way I understand the documentation, you should use "summation over nodes" only if the expression you integrate is a "reaction force", i.e., when the expression is something like the "reacf" operator applied to the dependent variable. So I don't know what's wrong with your model, but I don't think changing the integration setting is the way to go.
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Yes, I agree. I should stick to integration rather than summation over nodes. However, I don't understand why integration uses so much memory. My model has about 130,000 DOFs. This is not a big model. Can it be about the solver's running as fully coupled? Should I change it to segregated?
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
clear fully coupled could be the issue, but also depending on you you loop your variables, including integrations might make the matrices far from symmertic nor sparese, hence require quite a lot of RAM even if 130kDoF is not that much, if you have enough RAM some 16-64 bytes per DoF (or was it the double of that check the KB there is a tread there ?)
--
Good luck
Ivar
clear fully coupled could be the issue, but also depending on you you loop your variables, including integrations might make the matrices far from symmertic nor sparese, hence require quite a lot of RAM even if 130kDoF is not that much, if you have enough RAM some 16-64 bytes per DoF (or was it the double of that check the KB there is a tread there ?)
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hello,
Thank you for your reply.
Can you please tell me how I can check the tread?
Thank you for your reply.
Can you please tell me how I can check the tread?
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
at the KB one is here:
www.comsol.eu/support/knowledgebase/875/
and more here
www.comsol.eu/support/knowledgebase/1030/
but I'm missing the link to how many RAM bytes per DoF. But as one need at least 2-4 matrices, and their inverse, all in double precision. maybe complex too one can get then an estimate of RAM. This is to be corrected w.r.t the sparsity of the matrix which is different by orders of magnitude, depending on your model
for more on storage bytes per word single double quad precision and norms therearound see
en.wikipedia.org/wiki/IEEE_754
--
Good luck
Ivar
at the KB one is here:
www.comsol.eu/support/knowledgebase/875/
and more here
www.comsol.eu/support/knowledgebase/1030/
but I'm missing the link to how many RAM bytes per DoF. But as one need at least 2-4 matrices, and their inverse, all in double precision. maybe complex too one can get then an estimate of RAM. This is to be corrected w.r.t the sparsity of the matrix which is different by orders of magnitude, depending on your model
for more on storage bytes per word single double quad precision and norms therearound see
en.wikipedia.org/wiki/IEEE_754
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Thank you
I'll see what I can do.
Onur
I'll see what I can do.
Onur
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hello,
I repeated the same problem in 2D. With around 13,000 DOFs the problem worked properly with around 1GB. However, when I increased the elements; in other words, the problem increased to around 84,000 DOFs, the model worked with around 15GB (even in 2D). When I changed to "Summation over nodes", 15GB decreased down to 1GB with 84,000 DOFs.
I tried the opposite in 3D. I reduced the number of my elements in 3D and the model worked, but the coarse mesh is no good for me.
I suspect there is a bug in COMSOL. When I use an integration model coupling in the source of the general form PDE, the software, somehow, reserves a huge amount of memory. I don't understand why.
I wrote about this to the Support. I hope they return.
Thank you all,
Onur
I repeated the same problem in 2D. With around 13,000 DOFs the problem worked properly with around 1GB. However, when I increased the elements; in other words, the problem increased to around 84,000 DOFs, the model worked with around 15GB (even in 2D). When I changed to "Summation over nodes", 15GB decreased down to 1GB with 84,000 DOFs.
I tried the opposite in 3D. I reduced the number of my elements in 3D and the model worked, but the coarse mesh is no good for me.
I suspect there is a bug in COMSOL. When I use an integration model coupling in the source of the general form PDE, the software, somehow, reserves a huge amount of memory. I don't understand why.
I wrote about this to the Support. I hope they return.
Thank you all,
Onur
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
"summation over nodes" is really only reserved for "reaction forces" (that I use for postprocessing and not during solving), use first of all the default settings of COMSOL, as many has different implications, particularly in Solid and when you turn on the frame differentiation (geometrical non-linearity mode, and note that this is turned on for different specific cases such as contact ...)
--
Good luck
Ivar
"summation over nodes" is really only reserved for "reaction forces" (that I use for postprocessing and not during solving), use first of all the default settings of COMSOL, as many has different implications, particularly in Solid and when you turn on the frame differentiation (geometrical non-linearity mode, and note that this is turned on for different specific cases such as contact ...)
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Onur,
Try to use the nojac() operator around the integration variable when you use it in the PDE. That way COMSOL will not calculate the Jacobian of the integration variable. Check the COMSOL documentation if you are not familiar with that operator. In some cases the gradients of an integration variable result in a solution matrix that is not sparse, and that leads to excessive memory and solution times such as those you are experiencing. Convergence may be a little slower though.
Nagi Elabbasi
Veryst Engineering
Try to use the nojac() operator around the integration variable when you use it in the PDE. That way COMSOL will not calculate the Jacobian of the integration variable. Check the COMSOL documentation if you are not familiar with that operator. In some cases the gradients of an integration variable result in a solution matrix that is not sparse, and that leads to excessive memory and solution times such as those you are experiencing. Convergence may be a little slower though.
Nagi Elabbasi
Veryst Engineering
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hello Nagi,
Thank you for the input. With nojac(), the model could start with around 4GB, but I have faced the convergence problem as you have already talked about. I hope I can take care of it.
I cannot understand why this operator has to reserve so much memory. It doesn't make any sense to me.
Thanks,
Onur
Thank you for the input. With nojac(), the model could start with around 4GB, but I have faced the convergence problem as you have already talked about. I hope I can take care of it.
I cannot understand why this operator has to reserve so much memory. It doesn't make any sense to me.
Thanks,
Onur
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Onur,
The integration operator without nojac() takes too much memory because it may couple degrees of freedom at all the nodes involved in the integration domain. That means that there will be non-zero terms in the Jacobian/stiffness matrix relating these nodal degrees of freedom in places where initially there was none. Remember that standard finite element matrices are typically very sparse. That’s one of the reasons you can solve a 1 million degree of freedom model with only a few GB of RAM in a few minutes. The nojac() operator ignores those coupling terms but you end up with an approximate matrix. In most cases I have seen the model is still solvable and in much less time, but requires a few more iterations.
Nagi Elabbasi
Veryst Engineering
The integration operator without nojac() takes too much memory because it may couple degrees of freedom at all the nodes involved in the integration domain. That means that there will be non-zero terms in the Jacobian/stiffness matrix relating these nodal degrees of freedom in places where initially there was none. Remember that standard finite element matrices are typically very sparse. That’s one of the reasons you can solve a 1 million degree of freedom model with only a few GB of RAM in a few minutes. The nojac() operator ignores those coupling terms but you end up with an approximate matrix. In most cases I have seen the model is still solvable and in much less time, but requires a few more iterations.
Nagi Elabbasi
Veryst Engineering
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hello,
I think I have understood the algorithm, but I still don't find it very efficient. Or I am missing something.
All I want is that the solver calculates an integral over a domain and this integration will give me a scalar value. Then, I want this scalar value to be used in the PDE module. Nothing else. Why so much trouble with the jacobian? I thought segregation would help, but it hasn't, either.
I still find this strange.
Thank you,
Onur
I think I have understood the algorithm, but I still don't find it very efficient. Or I am missing something.
All I want is that the solver calculates an integral over a domain and this integration will give me a scalar value. Then, I want this scalar value to be used in the PDE module. Nothing else. Why so much trouble with the jacobian? I thought segregation would help, but it hasn't, either.
I still find this strange.
Thank you,
Onur
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
by looping in your model with the integration over many nodes (as Nagi says) you make your system highly non sparse and probably as well highly non lienear. The nojac() improves the sparsity, hence the time to solve (one loop).
The segregation only splits the full solver task up in smaller chunks (at best) but adds further iterations, so the overall gain in time is not there, while it can give you gain in total amount of RAM, which, if your active RAM size is overrun, has also an important impact on the solving time per iteration
--
Good luck
Ivar
by looping in your model with the integration over many nodes (as Nagi says) you make your system highly non sparse and probably as well highly non lienear. The nojac() improves the sparsity, hence the time to solve (one loop).
The segregation only splits the full solver task up in smaller chunks (at best) but adds further iterations, so the overall gain in time is not there, while it can give you gain in total amount of RAM, which, if your active RAM size is overrun, has also an important impact on the solving time per iteration
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi,
In most cases, using a segregated solver will have the same positive effect on memory consumption as using the nojac() operator, since it is a piece of the stiffness matrix providing the coupling between structural mechanics and PDE that will be fully populated. Using the segregated solver, the coupling terms only appear as 'right hand sides' and not in the stiffness matrix.
Without going into too much detail, there are however a some cases where the integration operator will also fill the non-coupled part of the structural mechanics stiffness matrix.
This may for example happen if you use the variable from the integration in a Dirichlet condition in another physics interface. For this case, the behavior can be changed using 'Apply reaction terms on' under Constraint Settings..
Regards,
Henrik
In most cases, using a segregated solver will have the same positive effect on memory consumption as using the nojac() operator, since it is a piece of the stiffness matrix providing the coupling between structural mechanics and PDE that will be fully populated. Using the segregated solver, the coupling terms only appear as 'right hand sides' and not in the stiffness matrix.
Without going into too much detail, there are however a some cases where the integration operator will also fill the non-coupled part of the structural mechanics stiffness matrix.
This may for example happen if you use the variable from the integration in a Dirichlet condition in another physics interface. For this case, the behavior can be changed using 'Apply reaction terms on' under Constraint Settings..
Regards,
Henrik
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Henrik
Thanks for the precision ,you give us more to chew on there ;)
--
Good luck
Ivar
Thanks for the precision ,you give us more to chew on there ;)
--
Good luck
Ivar