OpenSees Cloud

OpenSees AMI

Sometimes Tags Don't Matter

Original Post - 28 Nov 2022 - Michael H. Scott

Visit Structural Analysis Is Simple on Substack.

When building a model in OpenSees, you have to ensure that you have unique tags for your domain components (nodes, elements, patterns, time series, parameters, etc.), reliability components (random variables, limit state functions, etc.), and model building components (materials, sections, beam integrations, etc.). If you define a duplicate tag, you will get an error message.

The tags don’t have to be sequential and they don’t have to be strictly positive. For example, a user can number the nodes in a three node model 1, 2, 3 or 18, 0, -200. Same goes for elements, random variables, materials, etc. Also, the tags only have to be unique within a group of objects, not across all objects, i.e., you can define element 34 and random variable 34.

But there are some cases when programming a domain, reliability, or model building component where tags are not important, i.e., you can hard code–without any consequence–tags that will be duplicated when a user defines a model.

As a general rule, if the object will not be added to the domain or to the model builder, you can hard code whatever tag you want. This scenario happens most often with elements where you want to “mask off” or re-direct implementation details involving constitutive models.

Consider the following two examples.

BeamWithHinges Command

The input for the beamWithHinges element includes E, A, and I_z for the element interior (as well as I_y, G, and J for the 3D version). However, the beamWithHinges element is nothing more than a force-based element with special integration along the element length. To mask off these details, the OPS function for the beamWithHinges element command creates a local elastic section object, then passes the object address to the ForceBeamColumn class constructor. Essential code is shown below.

// tagI, tagJ, E, A, Iz from user input

SectionForceDeformation *secI = OPS_getSectionForceDeformation(tagI);
SectionForceDeformation *secJ = OPS_getSectionForceDeformation(tagJ);
ElasticSection2d elastic(0, E,A,Iz);

SectionForceDeformation *sections[6];
sections[0] = secI;
sections[1] = &elastic;
sections[2] = &elastic;
sections[3] = &elastic;
sections[4] = &elastic;
sections[5] = secJ;

// Pass sections to the ForceBeamColumn constructor

The tag of the elastic section does not matter. The command could have used tagI or tagJ instead of 0 as the elastic section tag and no errors would occur because the section never gets added to the model builder.

Unlike screenwriting a beloved superhero, the tragic backstory of those elastic sections does not matter to the ForceBeamColumn class.

ComponentElement Constructor

Frank developed the componentElement a few years ago to simplify the elastic-beam-with-zero-length-moment-rotation-springs-at-the-ends modeling approach that requires four nodes and a couple equalDOF commands. The componentElement handles the static condensation internally and can be used with any unaxialMaterial for the nonlinear end spring moment-rotation behaviors.

Anyway, I’ve recently run into cases where I want to use this modeling approach with elastic moment-rotation springs. It became a PITA to create elastic uniaxialMaterial objects, so I decided to overload the ComponentElement class constructor to take the elastic rotational spring stiffnesses kI and kJ. Essential code shown below.

// Original constructor
ComponentElement(int eleTag, ..., UniaxialMaterial *matTagI, UniaxialMaterial *matTagJ, ...)
{
   hinge1 = matTagI->getCopy();
   hinge2 = matTagJ->getCopy();
}

// Overloaded constructor
ComponentElement(int eleTag, ..., double kI, double kJ, ...)
{
   hinge1 = new ElasticMaterial(0, kI);
   hinge2 = new ElasticMaterial(0, kJ);
}

There’s no need to add those elastic materials to the model builder. From this point forward, the ComponentElement class does not care where these UniaxialMaterial objects came from.

Although the hard-coded internal tags pose no issues in model building, analysis, and standard recorder usage, problems could arise when dumping the entire model and analysis results with the MPCO, Gmsh, and VTK recorders, but I have yet to hear of any complaints.