SWHS: Missing Melt Fraction Constraint

[samm82]

The following constraint on the melt fraction doesn't formally exist in Drasil:

It's captured whenever the 𝜙 variable is used, like here in an IM, but the equalities are excluded:

Also interesting to note about the use of this condition is that it is redundant, since any value of T_P will lead to defined behaviour and a value of dT_P/dt.

1. What is the correct form of this equation?
2. Where should the constraint be captured? The melt fraction isn't really an input or an output, and that is where most (if not, all) of our data constraints are kept.
3. Should the redundant condition be removed from manual?

[smiths]

The value of phi is very important to this calculation. The problem cannot be solved without it. As far as I know the manual (case study) version is correct and we want to capture that information, or at least create an issue if we cannot enter it into Drasil. At some point you may be tempted to change the meaning of the physical equations so that it can be entered into Drasil. Please do not do that! That is what got us into this situation we are currently in. 😄

The data definition you show is correct, because phi is bounded by 0 and 1. It can be exactly equal to 0 (completely melted) or exactly equal to 1 (completely solid). In IM2 (manual version) the bounds are shown using less than (not less than or equal to) because when phi is equal to the bounds the behaviour is different.

The equation you show above from Drasil generated code is wrong. Someone in the past must have entered this because they didn't know how to do it the right way. We have a compound condition. While the PCM is melting the temperature doesn't change, this dTp/dt = 0. Once it is all melted, phi = 0, dTp/dt is no longer equal to zero. It will switch to the case where Tp > Tmelt^P. The liquid is now getting hotter.

The correct form of the dTp/dt equation is given in IM2 in the case study (manual) version. There are not 4 cases; there are 3 cases.

Phi should have the constraint information. If doesn't fit in the table of constraints (I don't think it will because phi isn't an input or an output, rather an intermediate value), you should make a notation about the bounds in a note for the DD for phi. As discussed with @JacquesCarette in the past, the better solution is to have types available so that phi can be given the type [0..1]. We don't have this in Drasil, so add a note so that the information is not lost.

[samm82]

Equation in IM fixed in #1069 and 17a4467