Discussion for redesign #159

srosenbu · 2024-09-30T17:48:45Z

To continue the discussion from #158:

Everything is currently very WIP and I am not happy with everything, so please give feedback;)

The code does not really work as a package, but you can build the conda env and then run the experiment.py and the problem.py which currently just print a serialized JSON of the classes.

joergfunger

IMO, this looks already very good, only the definition of the Problem is IMO too specific. In addition, I would put the virtual sensors in a class (Postprocessing?) that is one the one hand storing/measuring the data, and then also able to visualize them.

joergfunger · 2024-10-01T04:18:44Z

src/fenicsxconcrete/bcs.py

+class DirichletBCDefinition:
+    """
+    Definition of a time- and position-dependent Dirichlet boundary condition.
+    Note that functions cannot be serialized to JSON!


using the eval function, you could define a string and then convert that to a python function. The string can be stored in json

We can do that. To me, it screams security risk but then again, so would be importing any code you haven't written yourself

joergfunger · 2024-10-01T04:23:16Z

src/fenicsxconcrete/bcs.py

+    value: conlist(float, min_length=1, max_length=3) | Callable[[np.ndarray, float], np.ndarray] 
+
+@dataclass(config=dict(arbitrary_types_allowed=True))
+class BodyForceDefinition:


body force is very much mechanics driven, for the heat equation,this would be different (volumetric heat flux). I guess this would also just be a function of x and t and returns the corresponding term.

Yeah, I wasn't sure what to do here. What would be the general term for body force? So any integral

$$ \int_\Omega \mathbf b \rho \mathrm d x $$

source term?

I am not sure how we should generalize this. As far as I see it, the body-force definition is constant because gravity is constant. But how is it with heat flux? From this doc https://www.simscale.com/docs/simulation-setup/boundary-conditions/volume-heat-flux/ I get that it could vary with time and position

wouldn't that be the same as the functional representation of boundary conditions being a function of space and time? So there could certainly be constant or linear functions as standard (both relevant for body forces or linearly increasing boundary conditions) and then have the functional representation as additional option.

True, but my question is more related to what should be allowed. In an ideal world, the data structure would ensure that only valid values (like constant gravity) are allowed, but I guess that should then be the responsibility of the user.

Well, I guess it will be very hard to be able to define problems and test the validity beforehand (just from the syntax). And for Dirichlet BC I see now way around that, otherwise we are very limited, so then it makes no difference it that is added here again. But we could define two functions, one for BodyForce = constant and SpaceTimeDependentBodyForce(x,t).

joergfunger · 2024-10-01T04:25:34Z

src/fenicsxconcrete/experiment.py

+    dirichlet_bcs: list[DirichletBCDefinition] | None
+    neumann_bcs: list[NeumannBCDefinition] | None
+    initial_conditions: list[InitialConditionDefinition] | None
+    body_forces: list[BodyForceDefinition] | None


this is only mechanics

Only because of the body forces. Currently, each BC knows on which variable it should be applied, so the list of DirichletBCDefinition can contain bcs for any problem. I am however not sure about this design decision. Either the BC knows where it belongs because of some property, or alternatively it could know this because of its type. This would mean that for each physical problem we would introduce another BC type like TemperatureBC

when you provide the dof (T, d) as additional parameter, then it is completely clear. Just have to make sure that the two have the same dimension.

joergfunger · 2024-10-01T04:26:06Z

src/fenicsxconcrete/experiment.py

+    body_forces: list[BodyForceDefinition] | None
+    geometry: MeshGenerator
+    solution_fields: list[str]
+    time: tuple[float, float]


what is the time tuple, beginning and end?

Yes. We could also do a list of timesteps for the minimal amount of load steps and then the solver decides if any in-between steps should be taken.

joergfunger · 2024-10-01T04:27:00Z

src/fenicsxconcrete/experiment.py

+    geometry: MeshGenerator
+    solution_fields: list[str]
+    time: tuple[float, float]
+    material: MaterialDefinition


the material definition somehow has to be related to the geometry or physical components in case more than one material is used, which I think is something we should be able to cover.

True. Then the question is how we define a material. Is it just a string and then the solver needs to interpret that?

joergfunger · 2024-10-01T04:38:19Z

src/fenicsxconcrete/problem.py

@@ -0,0 +1,73 @@
+from pydantic.dataclasses import dataclass


In my original idea, there was no general problem definition class apart from a very basic on with a solve functionality (to be coupled with probeye or other sensor readings) and potential parameters that are read in from a json file in addition to the experiment. The option to store sensor data in the simulation could IMO provided by a completely separate class that is initialized with an expeiment (thus potentially has all information and names from the sensors) and is called with a FEniCS solution and the time and then knows how to store the virtual sensor readings. Everything else is very user-specific. Or is there an advantage of adding more functionality (quadrature, interpolation order, ..) as general features?

The problem.py is more an example for trying out how a full json would look like.

I personally see benefits for storing everything that I added because in a workflow, I would could then edit a json that is read by the simulation script instead of changing the script.

As for what should always be contained in a problem, I would say that it should always be able to return sensor readings and it should always be able to plot all variables that are stored. The input can be an experiment and a dictionary of parameters. But apart from that, I am fine with not restricting what a problem can do

I'm wondering what the advantage of the plotting capabilities in the problem is, instead of just adding that (and that is something everyone could decide himself) when creating the model. Then this class can be used afterwards to do the plotting (and does not even has to know the FE-problem), just the mesh, which is provided in the experiment. Then you can use any tool to visualize your results, potentially even in a postprocessing step (when having serialized the results) with a different software tool (visualizing ansys results with pyvista)

joergfunger · 2024-10-01T04:55:30Z

src/fenicsxconcrete/sensor.py

+        variable: The variable to be measured
+
+    """
+    location: tuple[float,float,float]


what are the units of the location? Always meter?

I did not take care of units yet

joergfunger · 2024-10-01T04:58:07Z

src/fenicsxconcrete/sensor.py

+
+    """
+    location: tuple[float,float,float]
+    variable: str


should the variables be restricted to the predefined enum instead of general strings?

I don't know yet. The enum would have the benefit that the input can very easily be checked, but it would also be restrictive. If you have a new material model with weird history variables, it would be easier to use the sting

joergfunger · 2024-10-01T04:58:43Z

src/fenicsxconcrete/sensor.py

+    unit: str
+
+@dataclass(config=dict(arbitrary_types_allowed=True))
+class PlotDefinition:


not sure what that class represents, a fieldSensor?

Basically yes. It is different from a sensor because, it needs to write to a file with each measurement

joergfunger · 2024-10-01T05:03:07Z

src/fenicsxconcrete/sensor.py

+
+    def measure(self, t: float):
+        for plot_function, function in zip(self.plot_functions.values(), self.functions.values()):
+            if plot_function is not None:


I see benefits in making that an external class (not within the standard problem). Thus, you would have to pass the fenics data structure to be able to measure from that. However, I also see that it has benefits to integrate that into BaseProblem, in particular the passing of the solution fields. However, the latter is somehow more difficult to read, since the variables are defined in a different class than where they are used.

aradermacher · 2024-10-16T08:03:03Z

src/fenicsxconcrete/experiment.py

+    initial = InitialConditionDefinition(value=[42.24], variable='density')
+    body_force = BodyForceDefinition(value=[0.,0., 9.81], variable='displacement')
+    mat = LinearElasticMaterial(name='steel', mu=1., lam=2.)
+    geo = MeshGenerator(parameters={'length': (1, 'm')}, mesh_tags={'left': 0, 'right': 1, 'top': 2, 'bottom': 3})


How can we cover the case that the mesh is given from other software (abaqus ...) or someone send me the mesh fiel and I have to use that? MeshGenerator = reading existing file and defining boundary groups (this would then be fenics stuff, or?)

aradermacher · 2024-10-16T08:04:37Z

src/fenicsxconcrete/experiment.py

+    bc = DirichletBCDefinition(marker=1, value=[0.,0.], subspace=0, variable='displacement')
+    neumann = NeumannBCDefinition(marker=2, value=[-42.0], variable='displacement')
+    initial = InitialConditionDefinition(value=[42.24], variable='density')
+    body_force = BodyForceDefinition(value=[0.,0., 9.81], variable='displacement')


How can we ensure that the body force is applied in the correct direction? We had some problems on that in the current version.

Based on the users coordinate system and the three components of the body force I would expect that to be unique, what was the problem in the current version?

aradermacher · 2024-10-16T08:20:12Z

src/fenicsxconcrete/names.py

+    Stress = Quantity("Pa")
+    Density = Quantity("kg/m^3")
+    Time = Quantity("s")
+


How would I use that if I have other, additional quantities? Would I create my own class AnnikaQuantity(Enum) or do we add that here? Some question for the SolutionFields Class ...

If you have something that is general, I would add that here, if that is something really user specific, I would just define that in your own problem definition.

aradermacher · 2024-10-16T08:21:55Z

src/fenicsxconcrete/problem.py

+        plots=[plot],
+        element_type=[FiniteElementDefinition(name="P", geometry_order=1, function_order=1, variable="displacement")],
+        quadrature_rule=[QuadratureRuleDefinition(name="Gauss", order=2, variable="displacement")],
+    )


I don't get where the real computation happens

I think exactly here, but I guess this is currently missing in the proposal. Maybe having some linearElastic computation here would help to better understand the idea and how the poblem definition is then used. And I'm not yet sure what these inputs would be, and in particular, if FEMProblemDefinition is a BaseClass or just a class everyone is reimplementing according to their needs.

aradermacher · 2024-10-16T08:26:37Z

src/fenicsxconcrete/material.py

+
+from typing import Callable
+from pydantic.dataclasses import dataclass
+


This is only a general definition of the material, right? At which point do we implement what happens if you choose e.g linear elasticity?

At the level of your solver (FEMProblemDefinition -though the name is IMO too long). You would then built your weak form and have an additional configuration file (but that does not have to be general but is really depending on your problem) that includes the material parameters (if you always use linearElastic), or the constitutive law and the parameters (if you decide to be able to allow on the configuration file level different material laws).

danielandresarcones · 2024-10-18T11:53:59Z

src/fenicsxconcrete/bcs.py

+@dataclass(config=dict(arbitrary_types_allowed=True))
+class DirichletBCDefinition:
+    """
+    Definition of a time- and position-dependent Dirichlet boundary condition.


How would the Dirichlet boundary condition be defined in time? Just passing a np.ndarray or a function?

That would need to be a function $f(x,t)\mapsto y,\quad x\in\partial\Omega$, so in python a Callable[[np.ndarray, float],np.ndarray] . For simplicity, a numpy array would be interpreted as a constant BC at every point in time

danielandresarcones · 2024-10-18T12:04:26Z

src/fenicsxconcrete/problem.py

+    plots: list[PlotDefinition]
+    element_type: list[FiniteElementDefinition]
+    quadrature_rule: list[QuadratureRuleDefinition]
+


Here, the different Experiment and Definition objects would only be used for initializing the problem and then can be forgotten, right? That would work with the model updating schemes, as then I can access directly the variables from FEMProblem (or the derive class) and update their values.

I would say, that most attributes could be forgotten after initialization. However, I haven't really considered the implementation part of the problems yet.

danielandresarcones · 2024-10-18T12:13:46Z

src/fenicsxconcrete/sensor.py

+    groups: dict[str, list[PointSensorDefinition | GlobalSensorDefinition | PlotDefinition]]
+    #plot_functions: dict[str, df.fem.Function | None]
+    #functions: dict[str, df.fem.Function]
+


One functionality that is important for me is to be able to create sensors from metadata and export the sensors metadata as well. To export it, that would probably be just a new method here for the class Sensors. To import a sensor from metadata, I guess we would need to write a new function that adds it to the sensors list. That should not be a problem, but means keeping and updating the json schema to the dataclass structure.

One of my design goals was that all classes have a very obvious representation as a dictionary/json, and you can just create a dataclass from a dictionary

sensor = Sensor(*dictionary)

Since the classes here only describe the sensors and have no methods, serializing and deserializing them should be what you are looking for

srosenbu added 2 commits September 20, 2024 13:34

Remove old code

9e0ab33

WIP

2868136

joergfunger requested changes Oct 1, 2024

View reviewed changes

aradermacher reviewed Oct 16, 2024

View reviewed changes

danielandresarcones reviewed Oct 18, 2024

View reviewed changes


		from typing import Callable
		from pydantic.dataclasses import dataclass

Discussion for redesign #159

Are you sure you want to change the base?

Discussion for redesign #159

Conversation

srosenbu commented Sep 30, 2024

joergfunger left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joergfunger Oct 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joergfunger Oct 9, 2024 •

edited

Loading