Recorder Issues w/ New Element Formulation

[blaiman]

Hello all,

I'm currently working on an element development which hopefully will incorporate local buckling on top of member buckling (LTB) for my research at UCSD. For the most part I have things compiled and running with the solution file. I am having a couple of issues though with this new element, one of which is related to the recorders. For some reason some lines of my output files have junk data which consist of multiple cases of "^@" and I'm not quite sure why this happens. My initial thought is that it might have something to do with the heap? I know for sure that I never had this problem when the element formulation was only taking into consideration member buckling. Any input would be great, thanks!

[fmk]

some ideas:
try spitting to the screen (i.e. use opserr) what it is you are sending back in the Information object ..
make sure in the setResponse you created the correct type of object and size of object for the getResponse.

[blaiman]

Thanks Frank; I've looked into my setResponse and getResponse and everything looks like how it should be setup and outputting forces. I'm noticing these ^@ symbols in my displacement recorders too though and I know for sure I never touched or changed anything in that class for my modifications.

[fmk]

do you have a script that does not use your element that generates these in the output. did you also try the opserr <<, the code may look fine but what you want to look at is the numbers that the code is spitting out.

[blaiman]

I never ran into any problems with script files that used the typical 3D beam-column element; this never even came up as a problem when we were running test cases for a 14 DOF beam-column element. The moment we incorporated 22 DOFs, the issue of the displacement outputs occurred. I have tried various things to check where the problem might be, one of which using the opserr<< method to see if the local forces of the element are outputted correctly. The element forces seem to come out fine... or at least they show me actual numbers/values instead of "junk" characters. The only time I've noticed random characters was when looking at the nodal displacement files. Depending on how many number of elements I'm using or the fixity of my nodal DOFs, the displacement output file will either have proper numbers throughout the file or some data with the occasional occurrence of "^@." I've been looking through all the various files where I had to modify to incorporate the extra DOFs but haven't seen to come across anything really that stands out to me as a red flag.

[fmk]

i am at a loss on this one. you may need to send code + small example that duplicates this if you can' figure it out.

[blaiman]

Another issue I apparently have noticed is that I still obtain reaction values for the extra DOFs I added even though the fixities at the corresponding nodes are released (= 0). Now... I think there might be a relation to these problems/issues with the fact that when I'm in debug mode and come across a message that says "Windows has triggered a breakpoint in OpenSees... This may be due to a corruption of the heap,..."

This message apparently shows up when I'm in the modified Corotational file I made; specifically in the line where it get the element projection:
xJI = nodeJPtr->getCrds() - nodeIPtr->getCrds();

The thing I find really strange though is that even though this comes as an issue in debug mode, I still can have an analysis run throughout all my time steps in the cases I was able to get to work (work properly too if I might add). Any thoughts to what may be causing this heap error based off this diagnosis? If I need to send my modified codes to have looked at, what would be my best option to do so? Thank you!

[fmk]

if not fixed, those reaction fores are the sum of nodal forces - element forces acting on the nodes .. if not 0, there are inertia and damping forces that are not included when you look at the reactions or 2) the node is not in equi with the convergence criteria you are using (switch to normUnbalance)

[blaiman]

I've made a proc file such that my analyses would be able to switch between test types mainly because the displacement increment test doesn't work as it used to for our 14 DOF element. I changed the default of an analysis to use normUnblance and that gets things working fine when used with the KrylovNewton algorithm. The problem that still occurs though is I get reaction forces at boundary conditions for my added DOFs when they are released and the random "junk data" I'd see in my output files.

[fmk]

if you follow the code you will see that when reactions are asked for we simply set the sum of reactions at nodes to 0 and then loop over elements asking them to add their contribution to the nodes. you might need to go into the source code and for a particular node tag see what values are coming from the element.

now in the analysis the loads, nodes and elements add their contributions to the global system of equation. so if there are 0 nodal loads at the fixed point and a small unbalance test is used these forces if 0 SHOULD mean that the reaction forces will also be 0 ..

if not:
1) the elements between the analysis step and the reaction step are not calculating the same resisting force .. when debugging you might also spit out the resistingForce() and see if the loads are the same as those in calculating the reaction later.
2) you have some mp constraints acting at these dof

[blaiman]

The error problem seemed to be "fixed"... There was an issue with the derivation of the element and we made some changes to it. Rerunning the same cases that initially gave us problems with the NormUnbalance test as the initial criteria seems to do the job. I did notice the issue that you brought up several responses ago though about using NormDispIncr and how it affects the reaction values. This seem to be the problem that was causing my "free" DOF reactions to blow up. Using the NormUnblance with the updated formulation definitely gives more reasonable values now.