Clean up variable naming

[rozsasarpi]

The code is relatively easy to read but there are some internal inconsistencies and inconsistencies in comparison with the structural engineering/finite element modelling terminology.

I'm collecting them here as I read and try to understand the source code.

• [ ] Materials <-> Sections
• [ ] Supports <-> piers
• [ ] class Material has no id attribute at initialization but it is added somewhere later and also used later when writing the tcl file; the Material id should be explicit and probably should be part of the BuildContext as well, e.g. incrementing it when a new material is added.

[jerbaroo]

I'm very happy to rename anything as you see fit :) Would you have any recommendation as to the naming approach i.e. structural engineering/finite element modelling terminology ?

[rozsasarpi]

I would suggest just to be very pragmatic and focus on the first point in my issue description.

From a structural engineering and finite element modelling perspective (the two match pretty much in terms of terminology):

Section and Material

• Section is solely the geometry + a reference to materials, basically expressing which materials should be attached to which part
• Material is solely the material: defining a material means the definition of a function that relates stresses to strains (or other material level properties but for this repo stress-strain is sufficient), note that both of these are sort of normalized quantities, i.e. not related to a particular element made out of the material but to a material point (continuum mechanics)

I think a Section and a Material class are justified but the current code is mixing the two above described categories. So sorting this out would be a bit more than just refactoring the code, it requires disentangling some classes to correspond to the above conceptual classes.

Maybe I should give it a try and make a PR but as you can see in my second PR I would need some briefing on some parts of the code..