I want to run a time history analysis in a 3D soil model with 35046 nodes and 31668 Bbarbricks elements.
I am using the PressureDependentMultiyield soil model with the option of user defined surfaces.
After my model passes the update of the material from elastic to plastic, I get this warning two times:
WARNING invalid nodeId: C:/Program Files/Tcl/lib/tcl8.5/reg1.2/tclreg12.dll - ad nodeId 1 forces
I recorded the OpenSees Interpreter when I ran my nonlinear model to make sure if the Warning was the cause of the time history to stop running. I actually found out that after the 2 warnings, I get this message:
FATAL: second_order_eqn: Complex roots
After that error the OpenSees interpreter closes.
I tracked the error down in the source code and it is an error that exists in the Multiyield surface code: (root)/trunk/SRC/material/nD/soil/MultiyieldSurface.cpp
Right now, I am running the same analysis using ElasticIsotropic material, Elgamal's automatic nonlinear curves and I get the same warning. However, both analyses start to iterate for the time history after the warning.
If I run the same user defined material I am getting the fatal error in a one column of 3D blocks, the time history works properly.
Do you know what can be the reason of the error?
Thank you in advance for your time.
FATAL: second_order_eqn: Complex roots
Moderators: silvia, selimgunay, Moderators
Re: FATAL: second_order_eqn: Complex roots
Hi，
I have the same problem with you when I am running my 2D soil model using PressureDependMultiYield material. This is the first time I see this kind of error. It is wired because I have been using same material for other models for quite a while. Did you mention that this error might be caused by the Multiyield surface code in your another posting? Could you give more details? I really have no idea how to resolve this error...Maybe we can figure it out together.
I have the same problem with you when I am running my 2D soil model using PressureDependMultiYield material. This is the first time I see this kind of error. It is wired because I have been using same material for other models for quite a while. Did you mention that this error might be caused by the Multiyield surface code in your another posting? Could you give more details? I really have no idea how to resolve this error...Maybe we can figure it out together.
-
MIRomero
- Posts: 15
- Joined: Thu Jun 16, 2011 11:14 am
- Location: University of Illinois at Urbana Champaign
Re: FATAL: second_order_eqn: Complex roots
Hi,
Thank you for your post. As I explained I am using the PressureDependent model with the user defined modulus reduction curves, if I ran the same model with the PressureDependent automatic curves I do not get the error.
I found the error here:
http://opensees.berkeley.edu/WebSVN/fil ... urface.cpp
It is a problem related with the matrices C and A, but it is not clear to me from that code how those are defined.
Also it is rare that I am having this error if I expand to 3D, because if I have a model with only one column of blocks it works properly. Hopefully Frank can give us some feedback.
Thank you for your post. As I explained I am using the PressureDependent model with the user defined modulus reduction curves, if I ran the same model with the PressureDependent automatic curves I do not get the error.
I found the error here:
http://opensees.berkeley.edu/WebSVN/fil ... urface.cpp
It is a problem related with the matrices C and A, but it is not clear to me from that code how those are defined.
Also it is rare that I am having this error if I expand to 3D, because if I have a model with only one column of blocks it works properly. Hopefully Frank can give us some feedback.
-
skamalzare
- Posts: 112
- Joined: Thu Jun 27, 2013 11:45 am
- Location: Seattle, WA
Re: FATAL: second_order_eqn: Complex roots
Hi,
I faced this problem today, and spent one full day to solve it. Then I said let's add a few lines here for future people. Hopefully, it can save some time for them.
The fatal error that we are seeing, is simply because OpenSees cannot solve a 2nd order (quadratic) equation somewhere in the model. The equation is defined as Ax^2 + Bx + C = 0, and OpenSees uses the delta method to solve it. Now if the delta (= B^2 - 4*A*C) is negative or A = 0, we will have fatal errors and the program crashes (look at the algorithm in the link provided by MIRomero above).
The problem is indeed a numerical error rather than anything mechanical. If we assign (let's say) improper input parameters to our model, the solver might crash somewhere.
In my case, I was working with a 3D model with two different materials: PDMY02 and PIMY. The study was about the dynamic behavior of a cylindrical rigid column inside soil during 48 different earthquakes. Recognizing this problem as numerical, I came with the following solutions:
1. I used closer input parameters to the default values, specially for the shear and bulk moduli. I got ~40 successful simulations. But as we know, we cannot always use the default parameters.
2. I used a more uniform permeability setting. In my model, the soil had k = 1e-4 m/s, and I had assigned k = 1e-6 m/s to the columns to essentially make them impermeable. The value 1e-6 is a good value, but you can get the same results with larger k's too. I increased my k and got ~45 successful simulations. But, again, we might not always be able to change our permeability.
3. I used a better geometry for my model. Taking advantage of symmetry, I was only modeling half of the geometry (half of the cylinder and the soil around it) and had assigned lots of extra boundary conditions to my model to resemble the symmetry. Boundary conditions either affect the stiffness matrix (penalty method) or the displacement matrix (transportation). In any case, they add to the numerical complexity of the model. Having that, I decided to forget the simplification and model the whole column with all the soil around it. This significantly reduced my BC-assignments. Fortunately, this completely made my model stable and I was able to simulate all my earthquakes successfully. I was also able to have my own input parameters both for materials and permeability.
In the end, any model can require its own modification. But my understanding is that this problem can be challenged better from a numerical perspective.
I hope this could help,
Best Regards,
Soheil Kamalzare
I faced this problem today, and spent one full day to solve it. Then I said let's add a few lines here for future people. Hopefully, it can save some time for them.
The fatal error that we are seeing, is simply because OpenSees cannot solve a 2nd order (quadratic) equation somewhere in the model. The equation is defined as Ax^2 + Bx + C = 0, and OpenSees uses the delta method to solve it. Now if the delta (= B^2 - 4*A*C) is negative or A = 0, we will have fatal errors and the program crashes (look at the algorithm in the link provided by MIRomero above).
The problem is indeed a numerical error rather than anything mechanical. If we assign (let's say) improper input parameters to our model, the solver might crash somewhere.
In my case, I was working with a 3D model with two different materials: PDMY02 and PIMY. The study was about the dynamic behavior of a cylindrical rigid column inside soil during 48 different earthquakes. Recognizing this problem as numerical, I came with the following solutions:
1. I used closer input parameters to the default values, specially for the shear and bulk moduli. I got ~40 successful simulations. But as we know, we cannot always use the default parameters.
2. I used a more uniform permeability setting. In my model, the soil had k = 1e-4 m/s, and I had assigned k = 1e-6 m/s to the columns to essentially make them impermeable. The value 1e-6 is a good value, but you can get the same results with larger k's too. I increased my k and got ~45 successful simulations. But, again, we might not always be able to change our permeability.
3. I used a better geometry for my model. Taking advantage of symmetry, I was only modeling half of the geometry (half of the cylinder and the soil around it) and had assigned lots of extra boundary conditions to my model to resemble the symmetry. Boundary conditions either affect the stiffness matrix (penalty method) or the displacement matrix (transportation). In any case, they add to the numerical complexity of the model. Having that, I decided to forget the simplification and model the whole column with all the soil around it. This significantly reduced my BC-assignments. Fortunately, this completely made my model stable and I was able to simulate all my earthquakes successfully. I was also able to have my own input parameters both for materials and permeability.
In the end, any model can require its own modification. But my understanding is that this problem can be challenged better from a numerical perspective.
I hope this could help,
Best Regards,
Soheil Kamalzare
---
PhD, EIT, Geotechnical Engineer
Condon-Johnson & Associates INC
PhD, EIT, Geotechnical Engineer
Condon-Johnson & Associates INC
-
jennyramirez
- Posts: 2
- Joined: Sat Nov 11, 2017 11:15 am
Re: FATAL: second_order_eqn: Complex roots
Hi all
Thanks for the previous posts, they are very helpful.
I’m dealing with a 3D mesh with about 29000 brickUP elements. Some of them don’t have perfect rectangular faces but irregular quadrilaterals faces instead. Elements also have different coefficients of permeability. in some areas, some elements have 3 or 5 orders of magnitude less than the other elements around. All the elements use the PDMY02 model (defining the yield surfaces inside the code). The original numerical constraints were define with the penalty method.
The model described above results in some convergence issues with a “complex roots” message.
I solved the problem when I used tranformation constraints and the Manzari and Dafalias model but I would like to use the PDMY model and penalty constraints if this is possible. Do you have any suggestions?
If the mesh is the problem here, I am wondering if there is any particular set of recommendations on how to deal with irregular meshes and the numerical issues that comes from it, specially when one uses PDMY. In case that some of you have dealed with this before, please let me know.
Thanks for the previous posts, they are very helpful.
I’m dealing with a 3D mesh with about 29000 brickUP elements. Some of them don’t have perfect rectangular faces but irregular quadrilaterals faces instead. Elements also have different coefficients of permeability. in some areas, some elements have 3 or 5 orders of magnitude less than the other elements around. All the elements use the PDMY02 model (defining the yield surfaces inside the code). The original numerical constraints were define with the penalty method.
The model described above results in some convergence issues with a “complex roots” message.
I solved the problem when I used tranformation constraints and the Manzari and Dafalias model but I would like to use the PDMY model and penalty constraints if this is possible. Do you have any suggestions?
If the mesh is the problem here, I am wondering if there is any particular set of recommendations on how to deal with irregular meshes and the numerical issues that comes from it, specially when one uses PDMY. In case that some of you have dealed with this before, please let me know.