PDE renaming

[TTitscher]

There are some issues regarding names.

Feel free to edit this post to add new entries

---

Strange names caused by name clashes with old NuTo:

• [ ] NodeSimple --> I suggest NodeDynamic - so we can later add a NodeFix.
• [ ] InterpolationSimple --> I suggest moving this to namespace InterpolationFem and call it class NuTo::InterpolationFem::Interface.

Strange names caused by inability to find better ones:

• [ ] DofCalcContainer (suggest calculations on dofs rather than its elements)
• [ ] ElementCollectionXYZ (contains a coodinate element and multiple dof elements)
  • ElementLayers
  • ElementStack
• [ ] namespace Nabla for differential operators. But IMO DifferentialOperators is too long. Maybe del? Rather unknown, I whould say...

I don't know the reason, it is just strange:

• [ ] ...

inconsistencies

• singular or plural namespaces and directories?
  • [ ] mechanics/cell or mechanics/timeIntegration vs mechanics/constraints or mechanics/elmeents

---

This is a rather simple issue, since it mostly involves renaming. But you get to know our code a bit better and get used to this whole git, branch, pull request, travis thing. So I would like to see some contributors other than the usual suspects. Don't hesitate to ask, if you need help!

[Psirus]

I'd prefer the AdjectiveNoun variant, as in DynamicNode and StaticNode, because I think it reads more naturally.

[vhirtham]

Not sure which order to prefer. Let's say, I have no idea about all the existing Node classes and want to check my options. NounAdjective ordering automatically groups them for me and I won't miss one.

Another candidate for renaming: ConstraintCompanion --- What does a companion do? The name does not specify its purpose, I think. Maybe something like ConstraintAssistant or ConstrainingAssistant or ConstraintBuilder or ConstraintConstructor or ConstraintAssembler or <Your ideas>

For ElementCollectionXYZ maybe something like ElementSetXYZ or SpatialElementsSet?

[TTitscher]

There are several companions in NuTo. MeshCompanion, ConstraintCompanion, EigenCompanion. They are named after the CompanionCube and will happily guide you through your NuTo experience. Don't you dare questioning their naming! :ghost:

[vhirtham]

Okay, than consider this as aggressive expansion of the Minions. I replace everything with <Name>Minion and obliterate the companions. :dagger:

[Psirus]

To get this somewhat back on track: what do you mean by "groups them"? When you're looking at an alphabetic list of all NuTo classes? Who does that? Imho "grouping" is what namespaces are for.

[vhirtham]

For example: If I want to get a header file per #include my auto completion would show me all possible headers of classes that are nodes just by typing Node. It is not necessary to use this kind of ordering, but what are the practical benefits of "reads more naturally"?

[Psirus]

I would like to re-propose a change in naming of the "Gradient & Hessians" stuff. For one, the name gradient is already used at too many locations. For another, the gradient is really just a residual if you don't have a potential of which you're taking the gradient, and similarly the Hessians are more generally just Jacobians. But because Jacobian is already used (in a more common use case), I'd just vote for Stiffness-, Damping- and Mass- matrices, which everyone understands immediately. This would also make code like this

for (auto& hessian0Function : mHessian0Functions)
    hessian0 += mAssembler.BuildMatrix(hessian0Function.first, dofs,
                                       Apply<CellInterface::MatrixFunction>(hessian0Function.second, t, dt));

for (auto& hessian1Function : mHessian1Functions)
    hessian1 += mAssembler.BuildMatrix(hessian1Function.first, dofs,
                                       Apply<CellInterface::MatrixFunction>(hessian1Function.second, t, dt));

more readable and less prone to "I mixed up 0 and 1"

for (auto& stiffnessFunction : mStiffnessFunctions)
    stiffness += mAssembler.BuildMatrix(stiffnessFunction.first, dofs,
                                       Apply<CellInterface::MatrixFunction>(stiffnessFunction.second, t, dt));

for (auto& dampingFunction : mDampingFunctions)
    damping += mAssembler.BuildMatrix(dampingFunction.first, dofs,
                                       Apply<CellInterface::MatrixFunction>(dampingFunction.second, t, dt));

[joergfunger]

I agree that the renaming of Hessian0,1,2 into stiffness, damping and mass would make the code better to understand, though this would somehow limit the generality. In the Newmark branch, time dependent problem is now implemented as a template parameter with the time derivative being a template function. This avoids duplication of code, since there is essentially no difference (on the global matrix level and structural level) between the different time derivatives. How would you then implement the different time derivatives - duplication? Regarding the renaming of gradient, it is essentially a residual, but only if it has been summed up. When looking at standard optimization schemes (determine a local minimum/maximum), this is usually called the gradient. Personally, I'm fine with both naming schemes for residual/gradient.

[pmueller2]

Change the name of the node selection routine NodeAtAxis to something different since it is essentially doing a NodeAtCoordinate but with with only some of the coordinates fixed.

Say in a 3D cube you do NodeAtAxis X, no offset, I would assume the result to be all nodes that are on axis X (so Y=Z=0). But instead you get all nodes that are on the plane perpendicular to it.