A problem about OpenSeesSP

[nvzitejing]

Hi,fmk
I use OpenSeesSP to analyse a soil-pile-bridge model. When np=1or2, it's ok. But np=4 or more, job aborted. How to solve this problem? system is Mumps.
Thank you in advance!

[fmk]

i need more info, any error messages along with aborted job?

[nvzitejing]

Hi,fmk

Thank you for your reply. When I run mpiexec -n 4 OpenSeesSP.exe AllSource.tcl, the error is:

special ele: 0
VERTEX ONE: 4

job aborted:
rank: node: exit code[: error message]
0: Kim-PC: -1073741819
1: Kim-PC: 123
2: Kim-PC: 123
3: Kim-PC: -1073741819: process 3 exited without calling finalize

[fmk]

looks like a bug (probably mumps) .. how big is the problem?

[nvzitejing]

Hi, fmk
Thank you! The model of soil-pile-bridge includes 4000 beam elements and 13542 solid elements. When np=3, it's ok! But np=4 or more, the Problem is still there. What's more, I have another problem. Before transient analysis, the static analysis of gravity must be done. But using OpenSeesSP, if np=2, after static analysis, a problem come out during the transient analysis. The transient analysis is kept on going, no recorder, no ending. The recorder stop at the last step of gravity analysis. Can't OpenSeesSP execute two continuous analysis cases ?

[fmk]

not sure what the problem is .. i am on holiday for another 1.5 weeks .. it should be able to do more than 1 analysis type .. again i think this is Mumps again .. errors like this pop up from time to time with mumps for larger problems .. i will need the script, but will be unable to look at it till i get back to my office.

[andreascj]

Hi fmk,

I also realized that recorder stops working with mumps while iterations are going on inside force-based elements in a transient analysis. My model has about 10,000 nodes and 10,000 force based fiber beam column elements. Any work-around or suggestions for this?

Thanks.

[fmk]

does the analysis finish and program shutdown correctly?

[andreascj]

no, it just keeps ongoing...

[fmk]

how do you know it's not working? .. the recorders only invoked record when convergence on an analysis step is reached .. if ele are iterating this stage as not been reached .. the files are only written when program closes and recorders are closed or when the write buffer fills up and the operating system flushes it .. in short the program has to close or recorders closed before the data is gauranteed to be there .. which brings me back to the question on how do you know it's not working?

[andreascj]

So that means iterations must be going on inside ele. I thought it's the problem with recorders. I was checking by refreshing the output files while program is running, which keeps iterating on different elements at different times. May be the buffer issue.