Efficient use of OpenSees interpreter - RAM usage

[kampix01]

Hallo,

The following is not a question in its original sense, it's a finding during my work with the OpenSees interpreter. But maybe some of you have comments and hits what I did wrong or where's the reason to it:

Actually I'm performing parametric studies where I have to do a lot of loop calculations. Imagine all parts needed for the calculation, e.g. the model or the analysis procedure is created and are working.

1st approach:
I opened some OpenSees interpreter in parallel and inside each OpenSees interpreter I called the specific calculation file. Which means one OpenSees 'process' is opened all the time till all loops are finished. There I had the problem, that my RAM always increased the longer the calculation was lasting till it aborted because no free RAM any more.

2nd approach:
I restructured my code a little bit. Then I opened a tclsh interpreter (the same number as OpenSees interpreter in approach one) and therein I opened all the calculation files (loops etc.) which were needed. JUST when I really need the OpenSees commands for calculation, a subprocess of OpenSees is started and therein one single calculation is performed, results are saved and afterwards the OpenSees subprocess is closed. This approach solved my problem with the RAM usage! now I'm able to perform almost twice of the calculations as in approach one, but now not limited of the RAM usage, now limited of the CPU usage (which is also lower than in approach one)

possible reason:
In my opinion there has to be a memory leak in OpenSees. But thats just because I've googled a lot to solve my initial problem. Maybe someone has the same experience or some useful hints.

regards
David

[fmk]

yes you have discovered a memory leak. w/o the script i cannot track it down. of course you could help, by isolating the element or material or commmand that is the source of the leak by changing material types, element types, ...

[kampix01]

Because of my memory problem, I broke my problem down to a single degree of freedom model where I did my IDA calculations for a certain period range (This is the reason for the variable mass and the variable Lambda_i in the MIK model, please find my model below). Maybe the model can help you finding the memory leak. If I can support you in any way, please contact me (david.kampenhuber@uibk.ac.at).

regards David


# delete former calculations ====================
wipe all

# DIMENSION and DOFs ============================
# global model dim and dof
model basic -ndm 2 -ndf 3;

# GEOMETRY ======================================
# main nodes
node 10 0.0 0.0;
node 20 0.0 1.0;
# additional node
node 18 0.0 0.0;

# MASS ==========================================
# nodal mass
mass 20 $sdof(m_i) 1.e-10 1.e-10;

# BOUNDARY CONDITIONS ===========================
# global boundary conditions
fix 10 1 1 1;
# local boundary conditions
equalDOF 10 18 1 2;

# MATERIAL ======================================
# MIK_BilinHystResp
uniaxialMaterial Bilin 2 1.0\
0.03 0.03\
1.0 -1.0\
$sdof(LambdaS_i) $sdof(LambdaC_i)\
$sdof(LambdaA_i) $sdof(LambdaK_i)\
1.0 1.0 1.0 1.0\
999.000 999.000\
309.700 309.700\
0.0 0.0\
2619.400 2619.400\
1.0 1.0;
# MinMax
set sdof(MatTag) 1;
uniaxialMaterial MinMax 1 2\
-min -800.0 -max 800.0;

# GEOMETRIC TRANSFORMATION ======================
set sdof(TransfTag) 1;
geomTransf PDelta 1;

# ELEMENTS ======================================
# column
element elasticBeamColumn 1\
18 20\
1.e2 1.e6 1.e2 $sdof(TransfTag);
# spring
element zeroLength 2\
10 18\
-mat $sdof(MatTag) -dir 6;

# DAMPING: RAYLEIGH =============================
# damping parameter
set sdof(alphaM_i) [expr 1.0*2.0*0.05*$sdof(omega_i)];
set sdof(betaKcurr_i) [expr 1.0*2.0*0.05/$sdof(omega_i)];
set sdof(betaKinit_i) [expr 0.0*2.0*0.05/$sdof(omega_i)];
set sdof(betaKcomm_i) [expr 0.0*2.0*0.05/$sdof(omega_i)];
# damping definition
rayleigh $sdof(alphaM_i) $sdof(betaKcurr_i) $sdof(betaKinit_i) $sdof(betaKcomm_i);

[m12s12sa]

I certainly don't have the solution, but I can report of having the exact same problem in a parametric analysis. The problem could possibly have worsened in the latest versions of OpenSees (when I wrote this script almost two years ago I didn't notice this problem and I was using a machine with half of the RAM - OpenSees version was 2.3.2), and surely is a lot worse in 64bit version of the executeble (this might be obvious, I know) - in fact I switched back to 32bit version for this specific reason.
David, I am very interested in your second approach, but I am afraid my IT knowledege is very limited. If I understand it correctly you have created a tcl script of this kind:

# begin main scrpt
- set all parameters (e.g list of parameters and other variables);
- create loops to perform parametric analysis (for, foreach statements);
- inside the most inner loop CALL OPENSEES
- source script(s) that create the model and perform analysis with current values of variables
- CLOSE OPENSEES
- complete the loops
#end main script

Ok, now what I dont't know... Where do you source the main script, what do you use as "tclsh interpreter "? How can you "CALL" opensees (the executable?) inside the main script?
This could be a very good workaround.
My script is extremely long and I don't know how I could possibly find the command that is causing this memory leak, even if it is very big (I have seen OpenSees going up to 5-6 Gb of RAM usage in Windows task manager...). All I know is that somehow every new iteration in the loops adds up to memory consumption, regardless of the command wipe being used.

Kind regards,
Francesco

[kampix01]

let me prepare a little example. please send me your email adress, then I can send the script you (david.kampenhuber@uibk.ac.at)