Dealing with time-dependency in the concrete material properties

[DanielGMorenaFhecor]

While developing examples for this repository, we needed workarounds to compute Ec_eff(t) = Ecm / (1 + phi(t)). Computing this property outside the concrete class is misleading, especially when a method already exists in the concrete class to return the Elastic Modulus (concrete.Ecm).

A smoother and more consistent approach would be to introduce a time property in the class or a method like concrete.Ecm_eff(t: float) -> float.

This may not be urgent but should be considered for future development.

[talledodiego]

Totally agree, we should add this into material classes. In general in material classes, a lot from code level 1 is missing.
For now we can use the workarounds. But we should implement it then.

Just thinking right now: maybe we could wrap all time-dependency in concrete class somehow?
Maybe adding too many methods in the concrete class can disorient the user? Maybe we could wrap with something like:

print(c25.fcd())
print(c25.Ecm)
print(c25.time.Ecm(t))
print(c25.time.fc(t))

I don't know if it makes sense...

[mortenengen]

I like the idea of having a .time namespace in the material classes which takes care of the property development with time. This should include at least:

• Strengths
• Stiffness
• Creep
• Shrinkage

We could for example create a base class for concrete property development which defines the interface. Furthermore, we can have concrete implementations for each design code, and assign an instance of this class to the .time attribute.

Any thoughts about this?