probeye integration

[TTitscher]

The estimate "application" performs a deterministic least square fit to estimate a model parameter. Our probeye package is supposed to solve that problem via various Bayesian methods.

Also (and this is not a coincidence ;) ) probeye is also based on concepts like model, experimental data, sensors and so on. So the task is to estimate a model parameter using probeye. Consider changing

response = LinearElasticity(parameters).__call__(sensors)

to

response = LinearElasticity(sensors).__call__(parameters)

to better match the probeye interface.

[ajafarihub]

I am not sure. Wouldn't it be the case that the model in fenics-constitutive should be somehow modified to a model fitting the framework of Probeye? To my eye, the former is more simulation purposed, whereas the latter looks to be a forward-model specifically designed for calibration, and these two might be considerably different. For instance, I have developed FEMU-F forward model, where in fact some data should be imposed to the "simulation model", which makes things really different than the original simulation model.

[eriktamsen]

I don't think it is easily possible, nor should it necessarily be the goal, that our "module" can be directly used as a forward model itself. However, I think it might be possible, to implement a general probeye forward model, that can take our fem problem as input.

[ajafarihub]

There are two things from my understanding:

1- IMO, if we wish to have a flexible setup for identification purposes, we kind of need to distinguish between:

• a model (I would call it 'simulating model') that simulates a certain experiment,
• a model (namely, forward model) that is used for calibration purpose. The FEMU-F forward-model that I briefly described: we feed data to the model and compare the force residuals; is a good example of such a difference between 'simulating model' and 'forward model'.

2- In view of @eriktamsen 's comment, should we prepare 'forward-model' that is going to be fed into a calibration module like probeye also in this module (fenics-constitutive) ? Or should the scope of fenics-constitutive module be first focused on only 'simulating', and the preparation of 'forward-model' should go to a sub-module or another module , or ... ?

[eriktamsen]

to 2. Basically I was saying, that from my point of view, we don't need to worry too much about probeye integration at the moment. Once the structure is setup, we can still build an interface to probeye (or do it faster, if someone is interested). I did not want to extend the "scope" of our module. The "forward model" is a class in probeye that could be extended to fit one of our fenics modules. in addition, I believe the calibration process should be a bit decoupled from a normal "simulation", so that it can be clearly defined in a workflow, and only rerun when eg new experimental data is given.

to 1. I think there is a misunderstanding. As far as I know, any model that does predictions in probeye is a "forward model". I am not familiar with your "FEMU-F" model therefore I do not follow your distinction.

[ajafarihub]

@eriktamsen I agree with you and in general, I think we have very similar viewpoints.

Besides, let me also explain FEMU-F: 'finite-element-model-updating method (force version)' in a short example. Let say we have a 3point-bending experiment, with displacement controlled loading. Most typically, when we want to calibrate an FE model of that, we take the model response; namely the displacement field, and compare it with the measured displacements (as reference). This is well known as FEMU of FEMU-D (the displacement version of FEMU). In FEMU-F however, we do other way around: we apply the measured displacements to the model and compute the force residulas. Then we compare them with reaction forces collected from the experiment. In this case, the forward-model is a model over which we apply all measured data as Dirichlet BCs, and this is different than our simulating model (I guess, what you termed as "normal simulation").

[joergfunger]

@ajafarihub I would argue that the model in FEMU-F and FEMU-D is similar (sensors, geometry, material model), the only difference is that you solve in two different ways. One is the standard mechanics model solving the weak form and getting displacements, whereas the other solves only for the nonlocal strains (with the input of all u) and outputs the residual at a specified set of nodes. So I could imagine that a FEMU-F model can be derived from a standard (FEMU-D) model by "just" adding another solve method that does not change u, but returns R. The nodes where R is returned would then e.g. be defined using the sensor concept and another set of sensors relates to the delta-u from you likelihood term that needs some interpolation between the locations where you have exp. data. This way, you might be able to use the same model class both for FEMU-D and FEMU-F. One tricky thing here might be how to handle history data to avoid confusion here.

[TTitscher]

As a future vision, all simulations could be done using the fenics modules and all statistics models could be defined and solved in probeye. If that is the case, we should strive for the most comfortable and user-friendly interaction of both.

With the change sketched in the very first post, we basically have a function that takes a dictionary {name: scalar} and returns a dictionary {sensor: vector/scalar}. This is really not far from probeye (probeyes requires the outputs key to be sensor_name instead of sensor). With some wrapper that automatically defines the module parameters and experiments in probeye (and I don't care if that is located in probeye or here or elsewhere), we're done, I think.

Including FEMU-F into probeyes explicit separation of model and experiment is another story. Here, I suggest that a specific fenics FEMU_F_problem takes the measured data from the fenics Experiment module and does the FEMU_F stuff. And you then tell the probeye experiment that you measured zeros. But please let's continue this specific FEMU-F discussion, if really needed, in private including Alex.