Energy balance

[kolozvari]

Thank you for clarifying. I have a few follow up questions.

1. How do I execute step 4 above (run gravity analysis without adding extra load)? How are the settings different from the initial gravity analysis?
2. How do I setup custom recorder "material.strains" for these materials?

I sent you my model via email a couple of days ago. I would really appreciate if you can implement these changes and send it back to me (or at least set it up so i can finish) ? Otherwise, please provide examples here.

Thank you

[STKO Team]

1. How do I execute step 4 above (run gravity analysis without adding extra load)? How are the settings different from the initial gravity analysis?

It's just a clone of the static analysis you already have. There is no difference. It's only necessary after you turn your material nonlinear, because it may happen that the prediction of the first gravity analysis is outside the initial yield domain of the materials.

2. How do I setup custom recorder "material.strains" for these materials?

In custom element results in the MPCORecorder

We sent you an e-mail with the modified file

[kolozvari]

Thank you very much!

[kolozvari]

Hello again,

After running the model with turned-on nonlinear soil material behavior I am experiencing this fatal error "FATAL:second_order_eqn: Complex roots". I looked into OpenSees code and it turns out that this occurs in MultiYieldSurface.cpp file that is most likely used by one of the material models I am using (either pressure dependent or independent). I understand that this is not an STKO issue, but it is creating problems for me and I was wondering if you have experienced this error before. Do you know what it means? Do you have any suggestions on how to fix it?

Also, I noticed that convergence is much slower. Do you have any tips on how to improve it?

Looking forward to hearing from you. Thank you!

[STKO Team]

Unfortunately, there is not much we can do about this issue.
This piece of code is not written very well:

Code: Select all

  if(C == 0) return 0;
  if(B == 0){
    if(C/A > 0){
      opserr << "FATAL:second_order_eqn: Complex roots.\n";
      exit(-1);
    } 
    return sqrt(-C/A);
  }

I think that sometimes C is close to zero (due to round-off errors) but not exactly zero, so it does not return in the C==0 check (in fact an exact floating-points equality check is highly discouraged).
The second issue is that, when they find this problem, instead of returning a boolean informing the material that the procedure failed, it simply crashes the program (exit command).

Now the only thing you can do is to reduce the time step hoping that this error does not show up.

[kolozvari]

I see. Thank you. Reducing the time step seems to helped and the analysis was able to proceed a bit further. However, I ran into another unusual issue. At some point the analysis stopped and showed the following error.

At line 6154 of file dmumps_part5.F
Fortran runtime error: Bad unit number in statement

Can you explain what this means and if there are any ways to fix it?

Thank you.

[STKO Team]

I've never seen this error.
It's deep inside the MUMPS routine.
Probably comes from some bad convergence issue in your model or something like a division by zero leading to garbage numbers.
Unfortunately, as I said before, these models are developed without many checks on the correctness of real numbers so these errors can appear.
Probably you can try to use a system that updates the tangent matrix only few times at the expense of more iterations