Should Data Definitions be able to reference Theoretical Models?

[bmaclach]

As mentioned in #1286, I wasn't able to reference a TM in the derivation of a DD because that would cause cyclic imports. In #1029 (comment) it was decided that TMs can reference DDs, and DDs cannot reference TMs. However, referencing a TM in the derivation of a DD felt like something I should be able to do. Since TMs are so general, it seems like it would be useful to be able to reference them in any derivation. So I am wondering if we should reverse our rule, and instead make DDs able to refer to TMs, and not the other way around.

I looked at our current examples to find cases where TMs are referencing DDs, since these would need to be changed if we went through with this proposed change. There are only 4 cases where this happens. 3 of them are in GlassBR and will disappear once the current TMs become IMs instead, which @vajihehm is working on. The 4th case is in SSP, and is shown below:

The sentence where the DD is referenced doesn't seem necessary to me; the fact that the status of the phase change depends on the melt fraction is made clear elsewhere in the SRS (such as in the IMs where the melt fraction is used in equations). What are your thoughts, @smiths?

[smiths]

Great question @bmaclach. I like that this process of formalizing the documentation is deepening our understanding of the physics. I can see your point in this specific example of the Theoretical Model referencing the Data Definition, but I can think of other cases where we will need this. For instance, if I write down the conservation of mass equation, I'll likely use density. I might want to then define density in a data definition. I could come up with more examples.

However, I agree with you that theories can be used to derive data definitions. (We have an example right now when we talk about the data definition for weight.) Maybe in the instances where this happens, what we really have is a general definition. According to the picture that I drew, general definitions can reference theoretical models.

What if we leave things they way they are, but change your data definition for weight to a general definition. Would that solve the current problem?

[bmaclach]

Since the DD for weight is used in the derivation for surface hydrostatic force (which is itself a DD), that wouldn't solve the problem, because then we would need to reference the weight GD from a DD. We would have to make surface hydrostatic force a GD as well (and then later make base hydrostatic force and slice weight GDs too, since they will similarly need the weight definition in their derivations).

[smiths]

I think this problem is coming up because of our (correct) move to improve our derivations. The derivations for data definitions will definitely need to reference the theories, and quite possibly the general definitions. The original idea was that the data definitions "supported" the theories, general definitions and instance models. We're going to have to rethink this.

@JacquesCarette, how important is it that we have a one way relation between theory and data definitions? Having a one way relationship seems like an artificial constraint to me.

I'm still going to think about the relationship between are different types of knowledge, but we might find that the relationship is more complicated than our first draft.

[JacquesCarette]

It has been my opinion for a long time that all there really exists is 'theories'. Now, some theories are quite small and have some particularly nice properties (such as making a single definition of 1 new computable item from known values, what you call Data Definitions) that may mean labeling them differently is useful.

Having said that, you had a clear body of evidence that seemed to point otherwise, i.e. that there were some important distinctions that were not just properties, but seemed to involve a 'grading' of different kinds of theories that could be nicely ordered. And that ordering had nice explanatory aspects to it too. So that was quite compelling.

But it looks like maybe that was not so after all. That 'grading' might be an illusion.

Now, what we must have, is a 'dependency ordering': we need to define new things in terms of old. What kinds of theories they are does not, in fact, matter. Of course, we might allow "mutually recursive definitions", but those should be 'local' (i.e. all contained in a single unit).

As far as referencing goes, the only hard thing is that there must be a dependency ordering. What it will mean for developing the examples is that we'll need to split up the files along that dependency ordering rather than some other arrangement (such as by DD, GD, etc).

Or, at least, that's my current thinking.

[smiths]

@JacquesCarette, I like the simplicity of the idea of everything being a theory, but we would still need a means to express the relationship between the theories. The relation we are looking at is abstraction. I really like the idea that one "general" theory can be refined to multiple instance models, depending on the assumptions that are made, coordinate system, etc. I wouldn't want to lose that information.

We should discuss further during today's meeting.

[JacquesCarette]

Hopefully the discussion at the meeting made sense! Does this mean that this issue has a resolution?

[bmaclach]

For the short-term, I know how to proceed (the DDs I was having trouble with will be GDs instead, so the old graph can remain the same). But it sounded like there'd be bigger changes in the long term. I don't know if the question of what the relationship should be between theoretical models and data definitions has been definitively answered. Unless we can safely say that in every case where a DD needs to reference a TM/GD, it's a sign that the DD should really be a GD? @smiths?

[smiths]

Yes @bmaclach, proceed with "fixing" our initial issue using GDs for DDs. It will require some deeper thought to determine whether this is the right long term fix. It probably isn't. There is some kind of refinement going on that we should capture, but it probably doesn't match what we currently have. To help us get a "feel" for things though, I think we are on the right track. Let's see what things look like with some GDs in place. As we add more derivations, this is going to come up again, and then we can think about whether we are on the right track or not.

[bmaclach]

With the merge of #1286, I've switched the DDs over to GDs, so that part is done (for the surface hydrostatic force at least).

[JacquesCarette]

@bmaclach What exactly is left to do on this one?

[bmaclach]

It's unclear what needs to be done, if anything. I think the question label on this one is correct. As far as I know, we still have not decided on an answer to the question posed in the issue's title.

[smiths]

I believe all of our current case studies respect the relationships given here:

https://gitlab.cas.mcmaster.ca/SEforSC/se4sc/-/blob/git-svn/Writing/SE4Science2019/RelationsBetweenTM_GD_IM_DD_A.pdf

In this picture theoretical models can reference data definitions, but data definitions cannot reference theoretical models. I don't have "proof" that we would never want a data definition to reference a theoretical model, but it makes sense that they cannot. The data definitions are supporting information. They aren't derived. The general definitions are derived from theories; the data definitions are just statements. I guess they are "atomic" in some sense. They are the information that is just given.

If we say that density is mass divided by volume. That is a data definition. If we derive this equation, then it would be a general definition. We've known for a while that a data definition in one document could be a general definition in another document. I worry that we may have hard-coded this information to too great an extent.

I think we can close this issue. If the model of the relationships given above proves to be incorrect because a new problem comes up, we can reopen the issue. Our current examples work. What will test them is adding the following to our case studies:

• derivations of equations (this will be necessary to fix the game physics example)
• refining our projectile example and combining it with the game physics physics (we have acceleration as a theoretical model in projectile, since everything is derived from this for projectile motion, but acceleration is a data definition for game physics. If we can reconcile this, we have made progress.)

I don't think we'll make further progress with keeping this issue open. I think we make progress when the next problem presents itself. For now, I'd like to operate under the hypothesis that data definitions (by definition) do not refine theoretical models. Until we find a contradiction, we can keep that model.