Dear Yesul,

I am sorry, but I still have not completely understood the situation your are considering.

Maybe you could compare your situation with the one in the reference model in the Section 2.1 of the UQLab Bayeisn inversion manual to help me (and others) to understand your situation.

In this situation, we have simply supported beam and it holds:

- The geometry of the beam is known and can be described by the given values for b, h and L.
- The beam is subject to a constant distributed load with then known value p.
- The Young’s Modulus E of the beam is only partially known and the knowledge, expert opinions, beliefs on the value of E prior to measurements one want to evaluate is represented by a prior density with a log-normal distribution with the presented values for the mean and the standard deviation.
- There is the model in equation (2.1) providing the mid spam deflection for given values of b, h,L, p, and E. This mid spam deflection is also denoted as the
*model output* and in the UQLab formulation the output value of the mfile. What is denoted as *input* for this model is not uniquely defined. On one hand, in the considerations for UQLab b, h,L, p, and E are *input*, i.e. the information about these parameters are stored in an INPUT object, see start of section 2.2.2. On the other hand, in other parts of the UQ community only E would be denoted as *input* while b, h,L, p, would somehow be under the hood parts of the model, and I have used in my post above the notion *non-UQ-Input* .
- Some measurements of the mid spam deflection have been performed, leading to the values shown in Table 1. These are values corresponding to observed model outputs, and these values need to be stored in the
`Data`

component of the structure description the Bayesian inverse problem, see Section 2.2.4 or the user manual for Bayesian inversion.
- Bayesian inversion is performed to derive an posterior density for the value for E by combining the prior density and the measurements of the mid spam deflection, i.e. of the model output.

So maybe you could compare your *measurement data (input)* to the situation above. As you may have realized, one would need to treat measured value for the model input and the model output different.

Greetings

Olaf