Drasil: Add Missing Quantities to FR1 Table in SWHS/NoPCM

[samm82]

The table for FR1 in SWHS and NoPCM is missing some quantities which should be added:

_Migrated from #1281_

TODO

• [x] Add tolerance values (#1330)
• [x] Add time step (#1334)

[samm82]

After adding the tolerances to SWHS, I realized that the word "tolerance" doesn't come up at all in the rest of the SRS - I think this is an issue, taking an input and not defining where its used.

@smiths Should something be added to the SSP SRS to account for these tolerance values? (ie. is this issue snowballing 😂)

[samm82]

@smiths Also, there isn't a time_step unital defined in SWHS and I'm not sure what information it should contain. (Does it have uncertainty, etc.)

[smiths]

@samm82, when you say tolerance values, you are referring to AbsTol, RelTol and ConsTol? The problem with saying how they are used breaks the abstraction of the requirements document. The requirements are to solve for the temperature, but we don't say how to solve for the temperature. However, when we actually solve it, we do it numerically and the calculations require tolerance values. The tolerances are inputs, so they are in the requirements document, but their meaning comes from the design, so the equations aren't given.

How best to deal with this isn't entirely clear. This would be a place where our code generator will eventually help. We can decide in the design stage what numerical parameters are needed, and they can be automatically added to the requirements and to the code, with a pointer to the design decisions. As we change these design decisions, the code and documentation can be automatically generated.

At this time, I think it would be distracting to do a deep dive on the tolerance values. At least for now, we can leave them as they are.

The same thing applies for the time_step. We are solving with an ODE solver, so we introduce a time step. However, there are other ways to solve an ODE. For instance, we could solve it symbolically. In that case, we wouldn't need a time_step. The presence of this input reveals a design decision.

Again, I think we want to avoid getting to involved in this at the moment. We need the inputs in the requirements for the code generation. As the design approach takes shape, the separation between requirements and design should be more obvious. @JacquesCarette and @bmaclach, this is something we should think about when we are thinking about the bridge between requirements and code.

[samm82]

@smiths So just to clarify, for now, I should leave the tolerance values in the table, but not add the time step? Or should I not add any and close this issue?

[smiths]

@samm82, I must have misunderstood your initial question. Yes, we should add the time step. It is needed in the code generation step.

[samm82]

@smiths Should it be an UncertQ basing it on time_final? If so, what would be the:
1) Definition (The short one (NP) is "time step for simulation", but UncertQs also have a longer def, ie. "The amount of time elapsed from the beginning of the simulation to its conclusion" for time_final.)
2) Space (I'm assuming its Rational, the same as time_final.)
3) Constraints (Bare minimum, it must be positive and can't be greater than time_final.)
4) Typical Value
5) Uncertainty (Assuming the default Uncertainty, same as time_final (10%))

Or should we not bother with these, since these fields won't be used yet? I'm not sure the best way to go about this.

I guess a better question would be: "In addition to its symbol, unit, and noun phrase, what other fields should it have?" so that we can frame its type from what supports what it needs?

[smiths]

I'm surprised to see that we have time_final as an uncertain quantity. We know the time we want the simulation to end with full certainty. It isn't a measured material property or processing property; it is an input the user decides. Similarly, we don't have any uncertainty with the time_step. We decide its value.

What other options are there for the classification of chunks? The simplest option is the best. We know that time_final and time_step are real numbers (rational numbers would be fine). As you said, we know that both times have to be positive, and that the time_step should be less than the final time.

[samm82]

An UncertQ is just a ConstrConcept with an Uncertainty, so I think we can move both time_final and the new time_step to be ConstrConcepts. This might lead to some typing conflicts, however.

[smiths]

If there are typing problems, we could consider, at least temporarily, making time_final and time_step UncertQs, but with 0% uncertainty. I'm not sure that @JacquesCarette would like that though. 😄

[samm82]

For now, I'm going to change it to a zero uncertainty, since this value appears in the Input Data Constraints chart, with an uncertainty column, and it looks like it would be a bad time trying to remove the uncertainty (although I can certainly try if that's the decision we decide to make 😁).

What would be a typical value (EDIT: and the definition) for time_step? And should it be a multiple of time_final or not necessarily. Again, I think it would be a headache to implement that (although I could be wrong) - it was just a thought I had. @smiths

[smiths]

Sounds good. The time step value of 10^{-3} would be a typical value. You don't need to worry about it being a multiple of time_final.

[samm82]

@smiths And what would a full, formal definition be for time step?

[smiths]

The time step is the finite discretization of time used in the numerical method for solving the computational model.

[samm82]

@smiths Should I define a zeroUncrt in Uncertainty for convenience, or would it be a bad idea to embed this potential hack too deep?

[smiths]

I don't think in the long term we will have uncertain quantities with a zero uncertainty. It just doesn't sound like a good design to me. Whether or not we should define zeroUncert for convenience is more a question for @JacquesCarette.

[samm82]

In that case, I think we shouldn't define zeroUncert then. My branch is ready to be merged then 👌

[JacquesCarette]

Right, long term, no uncertain quantities with zero uncertainty. I think in this case ConstrConcept is the right thing.

Also, 0 uncertainty numbers should not be floats!