Simple Hexahedral Mesh Not Supported by Transient Simulation

Clearly defined bug reports and their fixes
Post Reply
gschrank
Posts: 17
Joined: 21 Aug 2016, 05:40
Antispam: Yes

Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by gschrank »

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 Navier-Stokes 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 real-valued output when run as steady-state.
Attachments
case.sif
(2.37 KiB) Downloaded 298 times
mesh.zip
(461.54 KiB) Downloaded 285 times
raback
Site Admin
Posts: 4801
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by raback »

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
kevinarden
Posts: 2221
Joined: 25 Jan 2019, 01:28
Antispam: Yes

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by kevinarden »

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 Navier-Stokes solver. The NaN is because the solution diverged instead of converging.
gschrank
Posts: 17
Joined: 21 Aug 2016, 05:40
Antispam: Yes

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by gschrank »

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 real-valued. 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 steady-state run so you would see it is real-valued, but for some reason it won't attach.)

*Note: This is the very first linsys_b.data file that it creates. The first time-step, 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 (time-steps to big or even crazy boundary conditions), I can't think of a reason why under steady state conditions linear problem would be real-valued 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 real-valued. 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 271 times
gschrank
Posts: 17
Joined: 21 Aug 2016, 05:40
Antispam: Yes

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by gschrank »

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 non-linearities.

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 288 times
kevinarden
Posts: 2221
Joined: 25 Jan 2019, 01:28
Antispam: Yes

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by kevinarden »

When that occurs it is usually a unexpected/unitentional divide by zero (or the computer equivalent of zero)
kevinarden
Posts: 2221
Joined: 25 Jan 2019, 01:28
Antispam: Yes

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by kevinarden »

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 floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO
STOP 0
kevinarden
Posts: 2221
Joined: 25 Jan 2019, 01:28
Antispam: Yes

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by kevinarden »

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 non-linear itterations, but 20 was set as the limit. The linear system was set as direct, but the non-linear system was still itterating, but did not come anywhere close to converging.
raback
Site Admin
Posts: 4801
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by raback »

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

Code: Select all

Timestep Sizes(1) = 0.1   ! recommended
or

Code: Select all

Timestep Size = 0.1 
I added a fatal if the timestep is too small as a first aid.

-Peter
gschrank
Posts: 17
Joined: 21 Aug 2016, 05:40
Antispam: Yes

Re: Simple Hexahedral Mesh Not Supported by Transient Simulation

Post by gschrank »

Thank you so much!
Post Reply