Closed aradermacher closed 1 year ago
Would it make sense to define all possible fields in the base/derived material problems or maybe better keep those needed for the problem there and define extra ones only when adding/evaluating the relevant sensor? In either case, we should additionally check if the sensor is compatible with the chosen material problem at the moment of adding it to the problem, i.e., if the material has the required field/function unless the sensor is supposed to define it.
My first thought was, that defining them in the base material, would give a good overview of our naming "convention". The idea of Daniel, for the sensor to check if the required field is available when it is added to the problem, would however required the each material model only initializes the fields they require. I don't have a particular favorite solution. I think both "problems" are only minor. We are not implementing that many materials with different fields, that it would be too much to ask to double check the names of the required field. On the other hand, I also don't think it would be a problem to add a "wrong" sensor and only notice once the problem is running, or maybe even after.
We could have sth like a namedtuple
that contains all possible solution variables
SolutionFields = namedtuple("SolutionFields", ["temperature", "displacements", ...])
Then we would require that every MaterialProblem
contains an attriebute of type SolutionField
. Then, only the permitted names can be used, since the names in a namedtuple
can't be changed. I think it should be possible to only initialize the fileds that we need and all others are set to None
.
Edit: Maybe a dataclass
would be better than a namedtuple
To expand on my idea a little:
@dataclass
class SolutionFields:
displacements: df.fem.Function | None = None
temperature: df.fem.Function | None = None
nonlocal_strain: df.fem.Function | None = None
class DisplacementProblem(MaterialProblem):
def __init__(self, ...):
...
# Only set displacements, all other fileds remain None
self.fields = SolutionFields(displacements = df.fem.Function(some_space))
Now the sensor can always look into fields
and check which variables are used (not None) in the problem. We could also have another dataclass for internal variables like stresses, quadrature values, etc...
For the evaluation of sensors specific fields/functions are required to be defined in the material problem like problem.displacement/problem.V/problem.sigma/problem.epsilon ....
We should somehow define such things somewhere. We could do it in the base material problem class, where already some are included (displacment, temperature ...)
What do you think? Do you have better ideas?