Menu

Discussion Forum

New Discussion
Filtrer

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 avr. 2013, 04:38 UTC−4 General, Modeling Tools & Definitions, Parameters, Variables, & Functions, Structural Mechanics Version 4.3a 15 Replies

Onur Sevket Aslan
Send Private Message Flag post as spam

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
15 Replies Last Post 19 avr. 2013, 09:55 UTC−4
John H.
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 10 avr. 2013, 09:09 UTC−4
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.
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.
Onur Sevket Aslan
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 10 avr. 2013, 09:20 UTC−4
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?
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?
Ivar KJELBERG COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 10 avr. 2013, 12:36 UTC−4
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
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
Onur Sevket Aslan
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 11 avr. 2013, 06:51 UTC−4
Hello,

Thank you for your reply.

Can you please tell me how I can check the tread?
Hello, Thank you for your reply. Can you please tell me how I can check the tread?
Ivar KJELBERG COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 11 avr. 2013, 08:03 UTC−4
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
Hi at the KB one is here: http://www.comsol.eu/support/knowledgebase/875/ and more here http://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 http://en.wikipedia.org/wiki/IEEE_754 -- Good luck Ivar
Onur Sevket Aslan
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 11 avr. 2013, 08:42 UTC−4
Thank you

I'll see what I can do.

Onur
Thank you I'll see what I can do. Onur
Onur Sevket Aslan
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 13 avr. 2013, 02:23 UTC−4
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
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
Ivar KJELBERG COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 14 avr. 2013, 05:48 UTC−4
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
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
Nagi Elabbasi Facebook Reality Labs
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 14 avr. 2013, 08:20 UTC−4
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
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
Onur Sevket Aslan
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 16 avr. 2013, 07:30 UTC−4
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
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
Nagi Elabbasi Facebook Reality Labs
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 16 avr. 2013, 08:47 UTC−4
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
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
Onur Sevket Aslan
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 17 avr. 2013, 09:46 UTC−4
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
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
Ivar KJELBERG COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 17 avr. 2013, 14:28 UTC−4
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
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
Henrik Sönnerlind COMSOL Employee

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 19 avr. 2013, 02:31 UTC−4
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
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
Ivar KJELBERG COMSOL Multiphysics(r) fan, retired, former "Senior Expert" at CSEM SA (CH)
Send Private Message Flag post as spam

Please login with a confirmed email address before reporting spam

Posted: 1 decade ago 19 avr. 2013, 09:55 UTC−4
Hi Henrik

Thanks for the precision ,you give us more to chew on there ;)

--
Good luck
Ivar
Hi Henrik Thanks for the precision ,you give us more to chew on there ;) -- 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.

Suggested Content