Simple Hexahedral Mesh Not Supported by Transient Simulation
Simple Hexahedral Mesh Not Supported by Transient Simulation
I'm using Elmer 8.4 under Ubuntu 18.04. I used gnu compilers to compile the code
The simple attached 3D hex mesh will not run under transient simulations. It appears that when I switch the simulation type to transient, the solver outputs NaN for all entries in the matrix. The solver produces real valued entries when the simulation type is set to steady state. Although the example I've attached is with the NavierStokes equation, I've observed the problem also with the Diffusion equation and a User Solver that I built. This leads me to believe it is a problem somewhere in the solver code and not in any particular solver.
I have run 3D hex meshes as transient problems in Elmer in the past, so I'm not quite sure what is going on here.
You should simply be able to unzip the mesh file and run the case.sif under Elmer 8.4 to reproduce the problem. You can observe that the problem outputs a real valued matrix by changing the "Simulation Type" to "Steady State". Like I said, you can also try to mesh with other solvers. I did have a more complicated that case.sif that used Diffusion, and it also just gave me NaN output for the matrix when run as transient problem, but realvalued output when run as steadystate.
The simple attached 3D hex mesh will not run under transient simulations. It appears that when I switch the simulation type to transient, the solver outputs NaN for all entries in the matrix. The solver produces real valued entries when the simulation type is set to steady state. Although the example I've attached is with the NavierStokes equation, I've observed the problem also with the Diffusion equation and a User Solver that I built. This leads me to believe it is a problem somewhere in the solver code and not in any particular solver.
I have run 3D hex meshes as transient problems in Elmer in the past, so I'm not quite sure what is going on here.
You should simply be able to unzip the mesh file and run the case.sif under Elmer 8.4 to reproduce the problem. You can observe that the problem outputs a real valued matrix by changing the "Simulation Type" to "Steady State". Like I said, you can also try to mesh with other solvers. I did have a more complicated that case.sif that used Diffusion, and it also just gave me NaN output for the matrix when run as transient problem, but realvalued output when run as steadystate.

 Site Admin
 Posts: 4173
 Joined: 22 Aug 2009, 11:57
 Antispam: Yes
 Location: Espoo, Finland
 Contact:
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
Hi
It may be that the standard stabilized method is only available for incompressible fluids. If you want to use ideal gas you might try with bubble stabilization.
Of course if this is the case there should be some internal warnings.
Peter
It may be that the standard stabilized method is only available for incompressible fluids. If you want to use ideal gas you might try with bubble stabilization.
Of course if this is the case there should be some internal warnings.
Peter

 Posts: 1210
 Joined: 25 Jan 2019, 01:28
 Antispam: Yes
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
It didn't solve it in steady state, it just ran out of itterations. It is not a converged solution. In transient I believe that time step size is much too large, given the mesh size and the viscosity of the fluid. I also believe this case has too high of a Reynolds number for the plain NavierStokes solver. The NaN is because the solution diverged instead of converging.
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
I think there is a disconnect as to what we are talking about here.
It is not that the nonlinear system doesn't converge, etc. It's not even that the linear solver doesn't converge (the prescription I have in my case.sif is a direct solver anyway, so that doesn't even make sense.
It is that when I run this under transient conditions, the outputted matrix and vector to solve during the linear step is just a bunch of NaN entries. The linear solver can't even get started because the linear system is garbage; it's not realvalued. As an example, here is the linsys_b file during a attempted transient run. The linsys_a.dat file looks the same, it's just bigger so I can't attach it. (I tried to attach an example of the linsys_b file for a steadystate run so you would see it is realvalued, but for some reason it won't attach.)
*Note: This is the very first linsys_b.data file that it creates. The first timestep, the first iteration. From the very beginning, the linsys_a and linsys_b files entries are just NaN.
*Note: When I change the compressibility model from Perfect Gas to Incompressible, I still have the same problem. Both the linsys_a and linsys_b are completely populated with NaN.
*Note: I think this is what you get if you just run the case.sif I sent you (I can't remember if I had transient or steady state as the default in my case.sif).
Even if the actual problem is somewhat poorly conditioned (timesteps to big or even crazy boundary conditions), I can't think of a reason why under steady state conditions linear problem would be realvalued and the transient problem would be NaN valued for the linear system.
So remember, fundamentally what we are doing is solving a linear algebra problem Ax=b. What I am saying is that all of the entries for A and b are NaN when I set simulation type to "Transient" for all the solvers I've tried. And that from the first time step and iteration, they are NaN.
And I've observed this for a few different solvers. If you need a definite condition in which problem solves completely for a steady state problem and chokes in a transient problem, I can construct one. But I thought that the output from the assembler being all NaNs was such as clear problem that it didn't require that much extra effort.
So, the problem is the calculated entries for matrix and the vector are all NaN during when "Simulation Type" is set to "Transient". This means that the linear solvers, both iterative and direct, can't even get started because of course they can't. The linear system doesn't make any sense at all. This has been observed with a few different solvers: two of them part of the standard library and one that I wrote. The only warning I get is when the linear solver tries to solve this system, it seg faults because of course it is going to. When the "Simulation Type" is set to "Steady State", both the matrix and vector are realvalued. So they can be solved by the linear solvers.
I think this is a problem with the assembler when it tried to incorporate the mass matrix for these elements types, but I can't quite understand why.
Please also note, I used EclipseIDE to step through the assembly of the matrix of my User Solver Subroutine, and the Local Matrix was all real valued by the time the subroutine handed the arrays off to Default1stOrderTime. I didn't follow what was going on in Default1stOrderTime, so *maybe* the problem is in there. I don't really know what happens to my Local Matrix after it is handed off to this function.
It is not that the nonlinear system doesn't converge, etc. It's not even that the linear solver doesn't converge (the prescription I have in my case.sif is a direct solver anyway, so that doesn't even make sense.
It is that when I run this under transient conditions, the outputted matrix and vector to solve during the linear step is just a bunch of NaN entries. The linear solver can't even get started because the linear system is garbage; it's not realvalued. As an example, here is the linsys_b file during a attempted transient run. The linsys_a.dat file looks the same, it's just bigger so I can't attach it. (I tried to attach an example of the linsys_b file for a steadystate run so you would see it is realvalued, but for some reason it won't attach.)
*Note: This is the very first linsys_b.data file that it creates. The first timestep, the first iteration. From the very beginning, the linsys_a and linsys_b files entries are just NaN.
*Note: When I change the compressibility model from Perfect Gas to Incompressible, I still have the same problem. Both the linsys_a and linsys_b are completely populated with NaN.
*Note: I think this is what you get if you just run the case.sif I sent you (I can't remember if I had transient or steady state as the default in my case.sif).
Even if the actual problem is somewhat poorly conditioned (timesteps to big or even crazy boundary conditions), I can't think of a reason why under steady state conditions linear problem would be realvalued and the transient problem would be NaN valued for the linear system.
So remember, fundamentally what we are doing is solving a linear algebra problem Ax=b. What I am saying is that all of the entries for A and b are NaN when I set simulation type to "Transient" for all the solvers I've tried. And that from the first time step and iteration, they are NaN.
And I've observed this for a few different solvers. If you need a definite condition in which problem solves completely for a steady state problem and chokes in a transient problem, I can construct one. But I thought that the output from the assembler being all NaNs was such as clear problem that it didn't require that much extra effort.
So, the problem is the calculated entries for matrix and the vector are all NaN during when "Simulation Type" is set to "Transient". This means that the linear solvers, both iterative and direct, can't even get started because of course they can't. The linear system doesn't make any sense at all. This has been observed with a few different solvers: two of them part of the standard library and one that I wrote. The only warning I get is when the linear solver tries to solve this system, it seg faults because of course it is going to. When the "Simulation Type" is set to "Steady State", both the matrix and vector are realvalued. So they can be solved by the linear solvers.
I think this is a problem with the assembler when it tried to incorporate the mass matrix for these elements types, but I can't quite understand why.
Please also note, I used EclipseIDE to step through the assembly of the matrix of my User Solver Subroutine, and the Local Matrix was all real valued by the time the subroutine handed the arrays off to Default1stOrderTime. I didn't follow what was going on in Default1stOrderTime, so *maybe* the problem is in there. I don't really know what happens to my Local Matrix after it is handed off to this function.
 Attachments

 linsys_b_transient.zip
 (141.51 KiB) Downloaded 96 times
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
Here is another quick and simple example of a case.sif with this mesh. This time using the diffusion equation, so we don't have to worry about Reynold's number or any of that stuff. We don't even have to worry about nonlinearities.
This is just a really simple diffusion problem where the walls are set to zero and the initial condition is 1. Of course, the steady state solution to this is just the concentration being everywhere zero. However, when you try to do a transient problem, the matrix A and the vector b entries are all either NaN or Infinity.
If you just run this case.sif with the mesh I previously uploaded, you should see that behavior.
This is just a really simple diffusion problem where the walls are set to zero and the initial condition is 1. Of course, the steady state solution to this is just the concentration being everywhere zero. However, when you try to do a transient problem, the matrix A and the vector b entries are all either NaN or Infinity.
If you just run this case.sif with the mesh I previously uploaded, you should see that behavior.
 Attachments

 case2.sif
 (2.01 KiB) Downloaded 94 times

 Posts: 1210
 Joined: 25 Jan 2019, 01:28
 Antispam: Yes
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
When that occurs it is usually a unexpected/unitentional divide by zero (or the computer equivalent of zero)

 Posts: 1210
 Joined: 25 Jan 2019, 01:28
 Antispam: Yes
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
and that is the error I get, divide by zero
MAIN: 
MAIN: Time: 1/100 0.0000000000000000
MAIN: 
MAIN:
AdvectionDiffusion:
AdvectionDiffusion: 
AdvectionDiffusion: Solving for species transport
AdvectionDiffusion: 
AdvectionDiffusion: 
AdvectionDiffusion: Iteration step: 1
AdvectionDiffusion: 
AdvectionDiffusion: Bulk Assembly
AdvectionDiffusion: Boundary Assembly
SaveLinearSystem: Saving matrix to: linsys_a.dat
SaveLinearSystem: Saving matrix rhs to: linsys_b.dat
SaveLinearSystem: Saving matrix sizes to: linsys_sizes.dat
SaveLinearSystem: Just saved matrix and stopped!
Note: The following floatingpoint exceptions are signalling: IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO
STOP 0
MAIN: 
MAIN: Time: 1/100 0.0000000000000000
MAIN: 
MAIN:
AdvectionDiffusion:
AdvectionDiffusion: 
AdvectionDiffusion: Solving for species transport
AdvectionDiffusion: 
AdvectionDiffusion: 
AdvectionDiffusion: Iteration step: 1
AdvectionDiffusion: 
AdvectionDiffusion: Bulk Assembly
AdvectionDiffusion: Boundary Assembly
SaveLinearSystem: Saving matrix to: linsys_a.dat
SaveLinearSystem: Saving matrix rhs to: linsys_b.dat
SaveLinearSystem: Saving matrix sizes to: linsys_sizes.dat
SaveLinearSystem: Just saved matrix and stopped!
Note: The following floatingpoint exceptions are signalling: IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO
STOP 0

 Posts: 1210
 Joined: 25 Jan 2019, 01:28
 Antispam: Yes
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
The solution I get in steaday state is a velocity of 2.9E7, which does not appear to be reasonable for an input velocity of 0.005. It just quite after 20 nonlinear itterations, but 20 was set as the limit. The linear system was set as direct, but the nonlinear system was still itterating, but did not come anywhere close to converging.

 Site Admin
 Posts: 4173
 Joined: 22 Aug 2009, 11:57
 Antispam: Yes
 Location: Espoo, Finland
 Contact:
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
Hi
Well, well, this was peculiar little riddle.
In Elmer you can give timestep in two different ways. There is a keyword "Timestep Sizes" that is assumed to be an array with the same size as "Timestep Intervals". The code looks this with "ListGetConstRealArray". Now this has the handicap that it cannot be a variable of other stuff.
When we want to have a dependence on global variables, such as time itself, we can use "Timestep Size" which is not an array and is searched with function "ListGetCReal". I must admit that this is perhaps too closely the same.
Now, you had used "Timestep Size" but with the size declaration "(1)". This didn't go well. Instead of complaining the internal timestep was zero.
So either use
or
I added a fatal if the timestep is too small as a first aid.
Peter
Well, well, this was peculiar little riddle.
In Elmer you can give timestep in two different ways. There is a keyword "Timestep Sizes" that is assumed to be an array with the same size as "Timestep Intervals". The code looks this with "ListGetConstRealArray". Now this has the handicap that it cannot be a variable of other stuff.
When we want to have a dependence on global variables, such as time itself, we can use "Timestep Size" which is not an array and is searched with function "ListGetCReal". I must admit that this is perhaps too closely the same.
Now, you had used "Timestep Size" but with the size declaration "(1)". This didn't go well. Instead of complaining the internal timestep was zero.
So either use
Code: Select all
Timestep Sizes(1) = 0.1 ! recommended
Code: Select all
Timestep Size = 0.1
Peter
Re: Simple Hexahedral Mesh Not Supported by Transient Simulation
Thank you so much!