Add computer model and model implementation

[LillyG901]

Description of the issue

The ontology does not contain a way to separate the concept, implementation and the representation inside a computer of a model.
(related issue #1952)
It does however already contain numerical comptuer model. This term is similar but not broad enough for the intended use, since the existing term is limited to mathematical models.

This is a term needed for modeling uncertainties, more specifically the location of an uncertainty within a model.
See issue #1829

Ideas of solution

The term should be defined similarly to how it is described within this paper to properly work in the needed context.

The definition of model implementation within the paper is as follows:

Model implementation uncertainty deals with the uncertainties arising from the
implementation of the model in computer code. It addresses uncertainties related to
bugs and errors in the code, or hardware errors such as the well-known numerical
fault in early Pentium chips. Petersen (2006) calls this ‘technical model
implementation’; and Walker et al. (2003) call this ‘computer implementation’

The definition of computer model within the paper can be seen in @madbkr 's comment below.

Workflow checklist

• I discussed the issue with someone else than me before working on a solution
• I already read the latest version of the workflow for this repository
• The goal of this ontology is clear to me

I am aware that

• every entry in the ontology should have a definition
• classes should arise from concepts rather than from words

[stap-m]

Could you give an example for a computer model that is not a numerical computer model?
I think, for energy system modelling, the computer models used are typically numerical computer models. @areleu @Ludee @OpenEnergyPlatform/oeo-domain-expert-energy-modelling ?
We should discuss this term together with #1954 in one issue.

[madbkr]

From the paper:

The computer model is the implementation of the conceptual model in computer 
code. With respect to this model, a distinction is often made between the model 
structure and the model parameters. The latter can be further subdivided into 
parameters inside the model that are fixed and the input parameters to the model that 
can be changed to reflect different external developments and/or different policies. 

In contrast to that we have:
A numerical computer model is a mathematical model that is calculated by a computer.

So while I could not give an example for a non numerical computer model the focus of these definitions feels different. Maybe we could broaden the definition of numerical computer model instead of using it as is or defining a new term? Something like:

A numerical computer model is a mathematical model that is calculated by a computer. It is the implementation of a conceptual model.

[LillyG901]

I agree with @madbkr. I'm not aware of any specific computer model that is relevant in this context and isn't numerical, but the existing term is not usable in the context of uncertainties.

I'm not sure if it is possible to merge these to terms, but maybe I am missunderstanding the current definition of numerical computer model.
The definition seems to imply that a numerical computer model is already calculated by a computer. This sounds almost like the output of an implementation and would therefore not be the same as computer model.
If I do understand it correctly, it might be sensible to think about renaming one of the terms to avoid confusion.
If I'm wrong, I think @madbkr 's proposal would also clarify the current definition in order to avoid future misunderstandings.

Additionally it might be necessary to allow computer model to have the parts model structure, parameters inside the model, input parameters to the model, since the paper does make that distinction. These parts were not in the initial draft of how to model uncertainties in issue #1829, so maybe they are unneccessary for our purposes. But that depends on the intended use of uncertainties. Would it benefit the oeo to be able to describe the location of an uncertainty in such detail?
If so we should consider, that this would also affect numerical computer model should we choose to merge those terms.
If we merge them, I do think they would be similar enough, for this to not be an issue, but I think it is something worth considering.

[LillyG901]

One could come to the conclusion that the term we are missing is in fact just model implementation and that might be correct.
I'm not entirely certain how to seperate the terms model implementaion and computer model, since they both deal with uncertainties in the implementation of a model.
If I understand correctly uncertainties in the model implementaion are specifically related to code or hardware errors, wheras computer model uncertainties could also relate to parameters or the structural integrity of a computer model.
If this distinction is not relevant for our purposes it could also be easier to just merge these two terms. But maybe someone else could review the definitions above and help clarify how to model the differences between these two terms outside this specific context, since the terms are meant to be added as more general descriptors.

(I closed issue #1954 and edited this issue, so we can discuss their similarites in one place, as you requested.)

[UStucky]

I think, there are two discussions intermingled; one is the meaning of the term computer model or numerical computer model, respectively. I never could find a really valuable distinction between them. But let me try to give an example that hopefully describes my point of view.

Suppose we would like to model a pendulum in a gravitational field with friction by the medium surrounding it. It is sufficient to characterize the situation by a small bunch of numbers containing the length and the weight of the pendulum, the strength of the field and some coefficient to describe the friction. To run the model means to simulate the motion of the pendulum when it is deflected and an equation is needed to calculate it (the harmonical oscillator equation). The model is just the bunch of numbers, the simulation requires another series of numbers, that is the size of the deflection and maybe something like the starting time and the duration of the calculation to obtain a curve or or to obtain a time when the position of the pendulum is requested. It is all about numbers, and all about mathematical calculating.

On the other hand we have conceptional models of a (part of) a domain that characterizes this domain to the extend it is needed to describe it for some purpose where a computer program runs on this model. The model will contain numbers, but also strings, and, mainly if it is a model of respectable size, associations between parts of the model that are descibed by classes of different types which are ordered in a hierarchical tree. The program can be implemented as methods to the classes, ideally there are just classes of the model and methods of these classes. The output will tell the changes of the model. Of course, such a model is numerical in the sense that parts of the program simply calculate numbers out of numbers controlled by mathematical equations. The rest is a matter of string manipulation and changing associations between more complicated data structures (in principle, these are also characterized by numbers, since this all that a computer can do). So we have a model that is partly numerical, and if we are very nitpicking it is completely a numerical model, too, maybe with the prerequiste that all numbers are contained in the model and the program run does not need any input parameters.

Now, at last, I will come to the uncertainties, and I shall use the harmonical oscillator again. The uncertainties in the model are for example the approximation of the undamped motion as a sine (in the physical or mathematical model). The uncertainty in the implementaion is e.g. the uncertainty because of calculating with integers instead of real numbers (rounding errors).

[stap-m]

If I understand correctly uncertainties in the model implementaion are specifically related to code or hardware errors, wheras computer model uncertainties could also relate to parameters or the structural integrity of a computer model.

I agree. And from that point of view, this distinction makes sense for the uncertainties.

Additionally it might be necessary to allow computer model to have the parts model structure, parameters inside the model, input parameters to the model, since the paper does make that distinction.

We already have some concepts that relate to uncertainties of computer model in that sense: [exogenous data](http://openenergy-platform.org/ontology/oeo/OEO_00030029) and [program parameter](http://openenergy-platform.org/ontology/oeo/OEO_00000339)

A numerical computer model is a mathematical model that is calculated by a computer. It is the implementation of a conceptual model.

I like this extension to the original definition.

[stap-m]

One could come to the conclusion that the term we are missing is in fact just model implementation and that might be correct.

Yes, I could go with that.
With respect to model implementation, the paper mentions that it is also called ‘technical model implementation’, which I find clearer. Maybe something like "model code" might serve as (alternative) label aswell?
EDIT: We could interpret it as model component of a numerical computer model.

[madbkr]

If numerical computer model is meant like explained by @UStucky , I believe we should think about changing the definition of numerical computer model because I feel like it doesn't reflect that it only applies if only numbers are at play. I read it like the second example given and I would assume that I am not the only one who would make this mistake.

In that case the difference between numerical computer model and computer model is even more pronounced and I no linger think that merging them into one would be a good idea.

[LillyG901]

Should we maybe add a separate issue for clarifying the defintion of numerical computer model?

[LillyG901]

We can add technical model implementation as a model component of numerical computer model, but only if we are sure that we never need to refer to uncertainties within code that contains e.g. strings. (It could of course always be amended later if we don't need it right now), since the current numerical computer model does not seem to contain them according to the explanation above.

If we want to be able to refer to them we should add computer model with the distinction, that a numerical computer model truly only contains numbers wheras a computer model is simply the representation of a model within a computer, having the implentation as one of it's parts.

I think, for energy system modelling, the computer models used are typically numerical computer models.

If this is always the case I think we should be fine without the term computer model entirely.
But if we add it now we get a more general approach to models.
It mainly depends on if this would be of any use to domain experts.

[LillyG901]

I propose these definitions depending on what you'd prefer:

numerical model (should maybe be further discussed in it's own issue?) - is a mathematical model that is calculated by a computer and exclusively consists of numbers

1. We leave out computer model entirely

technical model implementation\model code - A technical model implementation is a model component that consist of the hardware and software realization of a model.

2. We add computer model for a more general approach

computer model - A computer model is a model that implements a conceptual model.
technical model implementation\model code - A technical model implementation is a (computer) model component that consists of the code used to represent the model within a computer, aswell as the hardware used to realize the (computer) model

[stap-m]

The definition of numerical computer model was agreed on in the oeo-dev team with several domain experts. I am reluctant to just changing it, since it represents what was understood as parent of "energy system model". In this sense, I don't think that the restriction to "just numbers" is really helpful for such complex energy system models - probably they are mainly numerical, which might be sufficient. If you find the label infelicitous, we could add another synonym.
And of course, if there is the need to differentiate types of computer models for energy system modelling at some point, we could still do that later.

[UStucky]

The more I reflect on the subject the more I come to the conclusion that computer models are just (conceptual) computer models; if the properties are all numerical, I guess there can be agreed to call them numerical; in general they consist - as I have stated above - of numerical and non-numerical properties and relations (associations) to more complex objects. Whatever can be caculated on a purely numerical model can also be calculated by a more complex model that contains all numerical properties of the former one and has been extended by arbitrarily many other classes and properties of any kind.

It may be a matter of what is calculated and maybe of how many non-numerical ("ballast") stuff which is irrelevant for the calculations the model contains, whether it is called "numerical" or not.

In the end it is dependent on how it is (strictly) defined (if it has been so strictly defined at all, and of course if we can refer to that definition) or otherwise what is custom in everydays researcher and engineer language. I wonder if anybody has ever reflected on that thoroughly enough :-D Maybe we are pioneers.

[LillyG901]

Maybe we are :)

If I can summarize this discussion:

We will leave numerical computer model as it currently is and we should not add computer model as a separate term, since it currently does not add any value to the OEO.

We should instead add an entity like
technical model implementation\model code - A technical model implementation is a model component that consist of the hardware and software realization of a (conceptual) model.

If that's alright and no one has any further comments/ideas on this topic, I would create a PR for this term once #1945 is merged.