BAMresearch / FenicsXConcrete

MIT License
0 stars 2 forks source link

define required material problem variables for sensors #106

Closed aradermacher closed 1 year ago

aradermacher commented 1 year ago

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?

danielandresarcones commented 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.

eriktamsen commented 1 year ago

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.

srosenbu commented 1 year ago

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 dataclasswould be better than a namedtuple

srosenbu commented 1 year ago

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...