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.

Getting "compressed" results

Please login with a confirmed email address before reporting spam

Hi everyone,

I'm trying to perform a very cumbersome nonlinear transient analysis of a large FE structure. The quantity of interest of this analysis, however, is not the full displacement field itself, but something that depends on it*. Of course, I can first do the full analysis and then compute what I need, however storing, reading and writing this amount of data is really painful. So, my question is: is it possible to run the simulation requiring a specific output (e.g. given by a postprocessing function), so that at each time step this specific output is returned (rather than the full solution)? Maybe using Matlab's Livelink? I think this would greatly speed up my job and ease the memory management.

Thank you in advance, Jacopo

*Specifically, I would need to project the full solution in time into a smaller subspace (spanned by the structure's eigenvectors).


4 Replies Last Post 20 mai 2022, 06:14 UTC−4
Magnus Ringh COMSOL Employee

Please login with a confirmed email address before reporting spam

Posted: 2 years ago 2 mai 2022, 10:21 UTC−4

Hi Jacopo,

Some of the ideas in this blog post migh be of interest: https://www.comsol.com/blogs/minimize-your-model-file-size-with-storing-solution-techniques/

Best regards, Magnus

Hi Jacopo, Some of the ideas in this blog post migh be of interest: Best regards, Magnus

Edgar J. Kaiser Certified Consultant

Please login with a confirmed email address before reporting spam

Posted: 2 years ago 2 mai 2022, 10:57 UTC−4
Updated: 2 years ago 2 mai 2022, 10:58 UTC−4

Hi Jacopo,

I know this issue in very large and especially time dependent models. Complex postprocessing may take even longer than solving the model. A method that worked for me was to define variables that evaluate during solving instead of doing it in postprocessing. E.g. you can do integrations in nonlocal couplings instead of doing them in postprocessing. Now, key to it is to store those variables in state variables. This way they become part of the solution and don't need to be recalculated during postprocessing. A normal model variable will be recalculated each time you call it in postprocessing, although it had been calculated during solving. The state variables are stored in the solution. Their disadvantage is that they don't hold a unit. You need to take care of that by yourself. During solving those additional calculations do not significantly increase the runtime, at least in the cases (mostly integrations) I was running.

The underlying problem to this is that postprocessing in Comsol runs in interpreted JAVA code, while everything during solving runs in C code. Well that is more or less my interpretation of all that, nobody can look under Comsol's hood and it is neither documented nor communicated what is really going on. I had asked the Comsol folks many times to bring the postprocessing to speed.

Ah, Magnus was faster in between.

Hope this can help, cheers, Edgar

-------------------
Edgar J. Kaiser
emPhys Physical Technology
www.emphys.com
Hi Jacopo, I know this issue in very large and especially time dependent models. Complex postprocessing may take even longer than solving the model. A method that worked for me was to define variables that evaluate during solving instead of doing it in postprocessing. E.g. you can do integrations in nonlocal couplings instead of doing them in postprocessing. Now, key to it is to store those variables in state variables. This way they become part of the solution and don't need to be recalculated during postprocessing. A normal model variable will be recalculated each time you call it in postprocessing, although it had been calculated during solving. The state variables are stored in the solution. Their disadvantage is that they don't hold a unit. You need to take care of that by yourself. During solving those additional calculations do not significantly increase the runtime, at least in the cases (mostly integrations) I was running. The underlying problem to this is that postprocessing in Comsol runs in interpreted JAVA code, while everything during solving runs in C code. Well that is more or less my interpretation of all that, nobody can look under Comsol's hood and it is neither documented nor communicated what is really going on. I had asked the Comsol folks many times to bring the postprocessing to speed. Ah, Magnus was faster in between. Hope this can help, cheers, Edgar

Please login with a confirmed email address before reporting spam

Posted: 2 years ago 20 mai 2022, 04:27 UTC−4

Dear Edgar and Magnus,

thanks for your replies, they've been helpful. Just one thing I've noticed: when I perform time analysis and I use mphgetu to retrieve the raw solution, although I selected only a specific domain for the output, I get the full solution. This means that actually the full results are stored somewhere, even if in the result nodes I see only the selected output. Is this a known behaviour?

thank you again,

Best Jacopo

Dear Edgar and Magnus, thanks for your replies, they've been helpful. Just one thing I've noticed: when I perform time analysis and I use mphgetu to retrieve the raw solution, although I selected only a specific domain for the output, I get the full solution. This means that actually the full results are stored somewhere, even if in the result nodes I see only the selected output. Is this a known behaviour? thank you again, Best Jacopo

Lars Gregersen COMSOL Employee

Please login with a confirmed email address before reporting spam

Posted: 2 years ago 20 mai 2022, 06:14 UTC−4

Hi Jacopo

You can use mphxmeshinfo to get the numbering of the DOFs of the solutions as they are numbered while solving. This numbering doesn't change even you choose to not save some of the results in the solution vector.

mphgetu always returns the full solution vector using the numerng given by mphxmeshinfo even in the case where you chose to not save some of the results. The returned u will contain zeros in the places where results were not saved.

-------------------
Lars Gregersen
Comsol Denmark
Hi Jacopo You can use mphxmeshinfo to get the numbering of the DOFs of the solutions as they are numbered while solving. This numbering doesn't change even you choose to not save some of the results in the solution vector. mphgetu always returns the full solution vector using the numerng given by mphxmeshinfo even in the case where you chose to not save some of the results. The returned u will contain zeros in the places where results were not saved.

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.