Master/slave is common terminology to describe relationships in many technical fields, e.g., between tables in databases or between devices in control systems. The terminology also appears in finite element analysis where the response of one node controls the response of another node through constraints.
However, this terminology is based on archaic relationships within our society. As engineers, we have other ways of describing constraints between nodes, ways that are actually more descriptive of the technical nature of the relationship.
While primary/replica is a suitable alternative for databases, and primary/secondary for control systems, retained/constrained is the most widely used alternative for finite element models. The response of the retained node is kept in the global system of governing equations while the response of the constrained node is removed from the equations, in one way or another, via a constraint handling method.
At the request of a dedicated OpenSees user, I endeavored to change all occurrences of master/slave to retained/constrained in the OpenSees wiki pages. This change is aligned with not only the mathematical concepts that these words represent, but also our profession’s efforts to build an inclusive community.
In addition to the wiki documentation, the terminology will be changed in the comments, variable names, recorder options, and other lines of the OpenSees source code. Example scripts hosted on the OpenSees GitHub site will be updated as well.
I encourage other software developers in engineering, whether the software is for commercial, instructional, or research purposes, to stop using this terminology and to help build an inclusive professional community.
For more information on why we should stop using the master/slave terminology, read this.
Update, July 5, 2020: OpenSees GitHub PR #381, changed terminology in SRC/ and EXAMPLES/ to mostly primary/secondary instead of retained/constrained. A few occurrences are in third party code (Tcl/Tk and AMGCL) and some recorder options maintained for backward compatibility of scripts.
Portwood Digital 
Hi P.D.
Forget how well you write and you inform. I will share your post.
Best,
LikeLike
Thank you, MSB!
LikeLike
Appreciate your thoughts.
LikeLiked by 1 person
Thank you, Gopal 🙂
LikeLike
While I appreciate your post and its sentiment, “Retained/Constrained” seems a little awkward, particularly the choice of “retained” since its meaning doesn’t indicate that it is the governing or controlling node, element, etc… Perhaps borrowing from familiar programming terminology using Parent/Child instead would better communicate the meaning of Master/Slave while avoiding the negative connotations associated with those terms.
LikeLike
Hello Andrew,
Thank you for the feedback. I agree, retained/constrained is not the best in all situations. It’s good for the transformation method because it reflects the math (static condensation). Parent/child or primary/secondary could be better for contact and impact models.
PD
LikeLike