Error occurred in umf4num: -1.00

[minoand]

I performed a EngenSolve with parabolic tetra elements and I get the message :
Error occurred in umf4num: -1.00
If I use linear tetraedral elements the analysis gives me results but too much rigid compared with nastran.
It's a free-free modal analysis (without boundary condition).
I used the tutorial solver parameter :

Solver 1
Equation = "Stress Analysis"
Eigen Analysis = Logical True
Eigen System Values = Integer 10
Linear System Solver = "direct"
Variable = "Displacement"
Variable Dofs = 3
Linear System Iterative Method = "BiCGStab"
Linear System Max Iterations = 1000
Linear System Convergence Tolerance = 1.0e-08
Linear System Abort Not Converged = True
Linear System Preconditioning = "ILU0"
Linear System Residual Output = 1
Steady State Convergence Tolerance = 1.0e-05
Nonlinear System Convergence Tolerance = 1.0e-05
Nonlinear System Max Iterations = 1
Nonlinear System Newton After Iterations = 3
Nonlinear System Newton After Tolerance = 1.0e-02
Nonlinear System Relaxation Factor = 1
Linear System Precondition Recompute = 1
End

Someone can help me to understand the problem ?

Thanks in advance for the answers,

bye

Andrea Mino

[raback]

Hi Andrea

Your linear system solver is "direct" which by default is umfpack. Probably you run out of memory. Use "iterative" instead.

Unfortunately the iterative solver may have problems in converging. For large problems multigrid of Trilinos package has been the best solver but that means that you need to compile yourself and run in parallel. There are other options as well. E.g. trying BILUn preconditioners with the Krylov methods.

Linear elements are known to be too stiff. There is a problem called "locking". You can use higher order elements by setting "Element = p:2". Unfortunately this again leads to larger linear system which may be more difficult to solve. We have experimented with hybrid multigrid with p2->p1 hierarchy first, followed by h-hiererchy. Seems to work nicely but may still be considered experimental.

-Peter

[minoand]

Many thanks Peter for your answer.
If I use the parameter suggest by you Element = p:2 on linear mesh
I recive the following error :
Operating system error: Not enough space
Out of memory


But with my parabolic mesh I recived the following message, after the assembly was finished:


MAIN: -------------------------------------
MAIN: Reading Model: sincronizzatore_para.sif
MAIN: -------------------------------------
Loading user function library: [StressSolve]...[StressSolver]
CheckSolverOptions: Setting > Linear System Direct Method < to:umfpack
OptimizeBandwidth: ---------------------------------------------------------
OptimizeBandwidth: Computing matrix structure for: stress analysis...done.
OptimizeBandwidth: Half bandwidth without optimization: 121534
OptimizeBandwidth:
OptimizeBandwidth: Bandwidth Optimization ...done.
OptimizeBandwidth: Half bandwidth after optimization: 2712
OptimizeBandwidth: ---------------------------------------------------------
MAIN:
MAIN: -------------------------------------
MAIN: Steady state iteration: 1
MAIN: -------------------------------------
MAIN:
StressSolve:
StressSolve: --------------------------------------------------
StressSolve: Solving displacements from linear elasticity model
StressSolve: --------------------------------------------------
StressSolve: Starting assembly...
StressSolve: Assembly:
: .................... 18%
: .................... 37%
: .................... 55%
: .................... 74%
: .................... 92%
: .........Bulk assembly done
DefUtils::DefaultDirichletBCs: Setting Dirichlet boundary conditi
SetNodalLoads: Checking loads for: displacement 1
SetNodalLoads: Checking loads for: displacement 2
SetNodalLoads: Checking loads for: displacement 3
DefUtils::DefaultDirichletBCs: Dirichlet boundary conditions set
StressSolve: Set boundaries done
EigenSolve: . Error occurred in umf4num: -1.00000000000000000

Is it possible to have out of memory problem if I see 1/2 Gb of free RAM before error ?

Do un Error explanation manual exist ?

I'll tried with iterative but the convergenze is very low ( 0.05 anfter 700 iteration).
I think is not the wright way.

Regards,

Andrea

[raback]

Hi Andrea

Yes, umfpack uses huge amounts of memory in 3D. My recommendation would be never to use it in 3D.

-Peter

[stoykov]

Hi,

on my experience, you may use umfpack for 3D problems if the DOF are about (or less) 400 000.
If the system is begger, use MUMPS with parallel processors. It works on my case for 2-3 millions DOF.

Regards,
Stan

[foadsf]

I'm checking the source code, and the error is thrown by this block of code:

Code: Select all

IF (iinfo(1) < 0) THEN
	PRINT*, 'Error occurred in umf4num: ', iinfo(1)
	STOP
ENDIF

the iinfo(1) variable also seems to be populated by

Code: Select all

CALL umf4num( Rows, Cols, Values, Symbolic, A % UMFPack_Numeric, Control, iInfo )

line. the called subroutine is :

Code: Select all

SUBROUTINE umf4num( rows, cols, values, symbolic, numeric, control, iinfo)
	USE Types
	INTEGER :: rows(*), cols(*)
	INTEGER(KIND=AddrInt) ::  numeric, symbolic
	REAL(KIND=dp) :: Values(*), control(*), iinfo(*)
END SUBROUTINE umf4num

I'm no FORTRAN expert, but that subroutine doesn't do much:

• exposes namespace of the "Types" module (that I can't find anywhere)
• declares some "assumed-size arrays" including the "iinfo(*)" but does not populate it!

to my best understanding the iinfo(*) variable is never populated and the error is caused by undefined memory behavior. But I'm most probably wrong!

[raback]

Hi

You point to some 6-year old fork. This is the current version:

https://github.com/ElmerCSC/elmerfem/bl ... tSolve.F90

The .src suffix precedes CMake version.

Still the code is the same. I think this is some memory allocation problem by Umfpack. It should be neater but I think that Umfpack just returns an error.

Edit: the routine itself is not there. It is just the interface.

You could try using "big umfpack" instead of "umfpack". It uses long integers to address memory.

-Peter

[foadsf]

thanks for the immediate reply. A couple of questions:

• is my understanding of the code valid? the array is undefined, right?
• can we please modularize UMFPACK? instead of including the whole code into the Elmer source code? it is very difficult to find issues and help with the development as is.
• I also tried the
  

  Code: Select all

  Linear System Direct Method = big umfpack
  

  argument and got this error:
  

  Error occurred in umf4sym: -8.0000000000000000
  Note: The following floating-point exceptions are signalling: IEEE_OVERFLOW_FLAG IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
  STOP 1

  which is somewhat identical to the other subroutine:
  

  Code: Select all

      SUBROUTINE umf4sym( m,n,rows,cols,values,symbolic,control,iinfo ) &
         BIND(C,name='umf4sym')
         USE, INTRINSIC :: ISO_C_BINDING
         INTEGER(C_INT) :: m,n,rows(*),cols(*)
         INTEGER(CAddrInt) ::  symbolic
         REAL(C_DOUBLE) :: Values(*), control(*),iinfo(*)
      END SUBROUTINE umf4sym
  

[raback]

Hi Foad,

That is not the subroutine. It is just the interface. What umfpack is doing is not seen there. I'm certain iinfo gets set there.

We use Umfpack version 5.1 because of this:

Versions 3 (March 2001) to 5.1 (May 2007) are licensed under the LGPL license. Versions 5.2 (Nov 2007) to date are licensed under the GPL license, with alternative commercial licenses available as well.

So if we would use fresh umfpack the users could not run non-GPL modules.

-Peter

[foadsf]

we could leave an option for the user. to compile against the LGPL or the GPL ones. How do you think about that?