Initialize command and "MKL Error: param on entry to DGETRF"
Moderators: silvia, selimgunay, Moderators
-
- Posts: 108
- Joined: Mon Sep 16, 2013 1:14 pm
- Location: University of Auckland
Initialize command and "MKL Error: param on entry to DGETRF"
Hello,
What does the "initialize" command do on a model? I have looked for documentation in the OpenSees webpage, but I haven't found anything. I have seen some examples where the comment before the call says "# Get Initial Stiffness".
The main reason I asked is because when I call the command, the error "MKL ERROR: Parameter 1 was incorrect on entry to DGETRF" appear on the screen and my OpenSees model crashes. btw I'm running NL pushover on 3D models. If I don't use the command the pushover model runs ok up until 1.5% drift (it runs a gravity analysis first and then the pushover) and then it crashes again with the same error message. I would like to note that despite the deformations look ok, the reactions make no sense.
I have look for information on the internet about the source of this problem and the closer I have got is that the DGETRF is a sub-routine to factor a matrix using Gaussian elimination with partial pivoting for long-precision real numbers, also that the "parameter 1" referred in the error message correspond to the number of rows in the matrix. Could it be that due to the geometry of my model I'm having LD rows or columns in my matrix? if yes, how could I avoid that? just by slightly changing the geometry so to keep the original problem?
Regards
What does the "initialize" command do on a model? I have looked for documentation in the OpenSees webpage, but I haven't found anything. I have seen some examples where the comment before the call says "# Get Initial Stiffness".
The main reason I asked is because when I call the command, the error "MKL ERROR: Parameter 1 was incorrect on entry to DGETRF" appear on the screen and my OpenSees model crashes. btw I'm running NL pushover on 3D models. If I don't use the command the pushover model runs ok up until 1.5% drift (it runs a gravity analysis first and then the pushover) and then it crashes again with the same error message. I would like to note that despite the deformations look ok, the reactions make no sense.
I have look for information on the internet about the source of this problem and the closer I have got is that the DGETRF is a sub-routine to factor a matrix using Gaussian elimination with partial pivoting for long-precision real numbers, also that the "parameter 1" referred in the error message correspond to the number of rows in the matrix. Could it be that due to the geometry of my model I'm having LD rows or columns in my matrix? if yes, how could I avoid that? just by slightly changing the geometry so to keep the original problem?
Regards
Re: Initialize command and "MKL Error: param on entry to DGE
initialize for some elements will set the initial tangent to use for rayleigh or initial stiffness iterations to be current tangent
try a different solver, Umfpack or ProfileSPD and see what error message is .. also send the script as i don't like crashes.
try a different solver, Umfpack or ProfileSPD and see what error message is .. also send the script as i don't like crashes.
-
- Posts: 108
- Joined: Mon Sep 16, 2013 1:14 pm
- Location: University of Auckland
Re: Initialize command and "MKL Error: param on entry to DGE
Hi, I sent the model to you by email.
-
- Posts: 108
- Joined: Mon Sep 16, 2013 1:14 pm
- Location: University of Auckland
Re: Initialize command and "MKL Error: param on entry to DGE
I finally found out what caused the error mentioned in the title, after long time avoiding it, so here I go: If a fibre section has over about 10000 fibres in total it will produce the above error message. Higher number of fibres will not yield any error, it just crashed without telling what was the source of the error.
In case you wonder why I had so many fibres...a typo... an extra zero in some of the patches, so be careful. I tested different fibre discretisations until I got to the number on the top. Other extra details just in case, I work on a 3D model with fibre-based BC elements to represent walls and columns, and shell elements to represent the floor system.
As a note, I run the model in two different HPC clusters and the message was "srun: error: compute-b1-042: task 0: Segmentation fault (core dumped)" which identify the error in the srun command on task 0 and the "Segmentation Fault(core dumped)" indicated that the code tried to access something that was not available or it didn't have permission.
I hope this may be useful for anyone facing the same type of error.
In case you wonder why I had so many fibres...a typo... an extra zero in some of the patches, so be careful. I tested different fibre discretisations until I got to the number on the top. Other extra details just in case, I work on a 3D model with fibre-based BC elements to represent walls and columns, and shell elements to represent the floor system.
As a note, I run the model in two different HPC clusters and the message was "srun: error: compute-b1-042: task 0: Segmentation fault (core dumped)" which identify the error in the srun command on task 0 and the "Segmentation Fault(core dumped)" indicated that the code tried to access something that was not available or it didn't have permission.
I hope this may be useful for anyone facing the same type of error.