asdeasoft.net

Dear STKO Team:
My model utilizes the ASDConcrete3D material, I upgraded my OpenSees-Solver veision from 3.4.0 to 3.7.2 (both are compiled versions by Prof. Tarque).
However, after completing the calculation using version 3.7.2, when I try to open the post-processing file, I receive a prompt: I am unable to load my MPCO file during the calculation process. And I can't open my post-processing file at all!
When I roll back to version 3.4.0, I could load MPCO files during the calculation process, but in that case I couldn't use ASDConcrete3D material for the calculation.
Do you have any solutions?

Can you share your model to see if we can reproduce the error?

Also you can check this:
Sometimes you run an analysis with let's say 10 processors.
The you re-run it with less, let's say 8, processors.
When you try to open it, STKO will find also the previous 9th and 10th, which belong to a previous model.
Make sure this is not the case for you

Hi STKO Team：
To simplify the model, I only created a three-dimensional structure of the soil.
But I encountered the same problem.
MODEL INFO:
·Soil dimensions: 48m * 21m * 30m
·Partitions: 16
·Perform elastoplastic gravity analysis on the model
Here are the problems I encountered.
I've also attached my model.

Looking forward to your reply!

UPDATE INFO：
Additionally, I created a model with partition 1, but the results still cannot be displayed.
This really confuses me.

One more question is that I want to use UMFPACK+RCM (with OpenSees) on this model, but it fails to converge in the first analysis step, while MUMPS+Parallel RCM (with OpenSeesMP)can converge. Why is that?

Looking forward to your reply!

One more question is that I want to use UMFPACK+RCM (with OpenSees) on this model, but it fails to converge in the first analysis step, while MUMPS+Parallel RCM (with OpenSeesMP)can converge. Why is that?

When you use more than 1 partitions, the only solver/numberer combination that can "UNDERSTAND" that each process is one part of a bigger model (domain decomposition) is MUMPS+ParallelRCM. All others will think that each process has its own stand-alone structure

Regarding you errors:
I still your errors that the end regarding the BAD TERMINATION. And it seems to be a bug in the InitialAnalysisStage on/off commands source code in OpenSees.
I tried to comment those 2 commands and the error disappears.
Anyways, in my case I can see the output with both the InitialAnalysisStage command commented and not commented.

Can you try to comment it out, just to understand if it's the bad termination that corrupts your files?

STKO Team wrote: ↑

Thu Jun 18, 2026 8:36 am

When you use more than 1 partitions, the only solver/numberer combination that can "UNDERSTAND" that each process is one part of a bigger model (domain decomposition) is MUMPS+ParallelRCM. All others will think that each process has its own stand-alone structure

I think my wording might have been a bit off. What I meant was: I wanted to check if there was a problem with OpenSeesMP, so I removed the partitioning and switched to OpenSees for the calculation. For the same model, the unpartitioned UMFPACK+RCM (with OpenSees) failed to converge in the first analysis step; however, the partitioned MUMPS+Parallel RCM (with OpenSeesMP) converged.

So, for the same model, why does the choice of system and numberer have such a large difference in the calculation results?

Can you try to comment it out, just to understand if it's the bad termination that corrupts your files?

Commenting out InitialAnalysisStage on/off really solved the problem; it ran without errors, and the .mpco file could be opened and viewed normally. But how did this problem occur? Will this issue persist when using the InitialAnalysisStage on/off command in OpenSees-Solver veision 3.7.2?

I think my wording might have been a bit off. What I meant was: I wanted to check if there was a problem with OpenSeesMP, so I removed the partitioning and switched to OpenSees for the calculation. For the same model, the unpartitioned UMFPACK+RCM (with OpenSees) failed to converge in the first analysis step; however, the partitioned MUMPS+Parallel RCM (with OpenSeesMP) converged.

So maybe it's due to some instability (like unconstrained DOFs), and in those cases, some solvers might be more tolerant than others.

Commenting out InitialAnalysisStage on/off really solved the problem; it ran without errors, and the .mpco file could be opened and viewed normally. But how did this problem occur? Will this issue persist when using the InitialAnalysisStage on/off command in OpenSees-Solver veision 3.7.2?

It has been fixed last month, so it will disappear on the next OpenSees version. Furthermore it seems they detected it with SSPBrick elements. Maybe it doesn't happen with other elements
https://github.com/OpenSees/OpenSees/pull/1754

So maybe it's due to some instability (like unconstrained DOFs), and in those cases, some solvers might be more tolerant than others.

Thank you for your explanation.

it will disappear on the next OpenSees version

Will this be updated in OpenSees-solver?
If not, do I need to download the OpenSees source code for compilation?

In addition, you said "with sspbrick elements", I adopted bbarBrickUP and brickUP elements, and the result are still BAD TERMINATION. So now I think it is the problem of the InitialAnalysisStage command

Will this be updated in OpenSees-solver?

It will, but that unofficial installer will be made available by professor Tarque. I think in a month form now, but we cannot be sure.
If you are able to compile opensees it's fine