Solution Method Variability: NoPCM Example

[smiths]

The NoPCM case study uses an ODE solver to find the temperature of the water over time. However, the noPCM version is simple enough that a direct (analytical) solution of the ODE is possible. Rather than use an ODE solver, the function could be coded directly into the software. This would change the design, since no ODE solver module, and no ODE defining modules would be necessary.

In our future design language, it would be nice to capture the decision of which method to use. This kind of decision is at a higher abstraction than the usual one where we have an ODE solver and switch between methods. This is a switch from using an ODE solver, to not needing one at all.

[JacquesCarette]

Excellent! This is indeed a rather high-level decision, and I imagine rarely, if ever, properly captured, never mind made changeable, in most software.

[JacquesCarette]

@bmaclach Did you ever look at this? Could your design language handle this variability?

[bmaclach]

I've seen this issue, but I haven't spent a lot of time on it. It could be added as a variability to the design language, but there are some interesting repercussions which were mentioned in #1498, specifically that the inputs to the problem change if you are solving it numerically vs. analytically, but the list of inputs is currently independent of the chosen design. So some infrastructure changes would be needed too.

[smiths]

I'm sure that everyone on this thread already knows this, but the problem of different design choices requiring different inputs is going to come up in other instances. Here we are talking about a design variability. The design choice of an analytical solution versus a numerical solution. Even within numerical solutions, different algorithms will often require different parameters. If we start varying requirements, we will also have instances with different inputs. One example we've talked about in the past is removing the assumption of a perfect insulator on some of the boundaries for SWHS or noPCM. This is a trivial change for the ODE, but it will require another input parameters (the heat transfer coefficient). An example like this will really take our framework up a notch. :smile:

I think this kind of change is outside of the current scope of the work, but it something that maybe @bmaclach can talk about in the future work section of his thesis.

[JacquesCarette]

Yes, given the repercussions, definitely outside the scope. But nice that we're at the point of realistically discussing it, and that it could be done, given time.

[cd155]

@smiths I just wonder to know currently is there an SRS to solve the NoPCM in close form. If there is no SRS available, would you mind pointing to a source that solves NoPCM in close form? I think it would be useful to see the difference between analytic one and numerical one as an example in NoPCM.

[smiths]

The version with an analytical solution would look very similar to the current version. In the previous terminology (not using the refinement of theories approach we are currently working on), the instance model IM:eBalanceOnWtr would instead be viewed as a general definition. We would then add a new instance model that solves the ODE introduced in the general definition. The steps to solve the ODE are fairly straightforward, as shown here:

http://web.math.ucsb.edu/~myoshi/cooling.pdf

To map this solution to our work, k = 1/tau_W, M = T_C and T = T_W. Solving the ODE gives you an equation that can be evaluated for any value of time.

[cd155]

The closed-form of NoPCM come with the following solutions

1. For cooling, M - T < 0 T = M + A ⋅ e ⁻ᵏᵗ, A = e⁻ᶜ

2. For heating, M - T > 0 T = M - A ⋅ e ⁻ᵏᵗ, A = e⁻ᶜ

3. I think we have to list when M - T = 0 (this is not in the previous solution) T = M

M, k, t are inputs, C is a constant

@smiths I just wonder to know is the C in both equations (1,2) is just an arbitrary constant?

I try to think of a manual solution, how this should be written in code. The T is the output we want to calculate, but it is unknown when the user enters inputs.

[smiths]

@cd155 we have the assumption that the tank is only charging, not discharging (Charging-Tank-No-Temp-Discharge). This means that we have the case where the temperature will be rising until the temperature in the tank matches the temperature in the coil. (This is your case 2 above.)

The case where T = M means the ode is dT/dt = 0, which has a constant solution of Tw(t) = constant, and with the initial conditions that Tw(0) = Tinit, we have the solution Tw(t) = Tinit. You don't need to solve for this case because it is a special case of the two solution you listed. You can see this if you solve for A. More on this next.

You find C by solving for the initial conditions. It is probably actually better if you just leave it as A, rather than exp(-C). It is simpler that way. Every ODE has an initial condition so that you can get a unique solution. For our problem we have Tw(0) = Tinit. You can substitute Tw(0) = Tinit into your equation 2 to solve for T(t), as follows:

T = Tc - (Tc-Tinit)*exp(-kt)

You can find T for any value of t. You know Tc, Tinit and k. This is the same thing that the numerical code calculates, but it is calculated differently in each case.

For the case where M = T, that means that Tinit = Tc (the coil and the initial temperature are the same). If you substitute that into the above equation, you find that T = Tc. As I mentioned above, that means that you don't have to handle the case where M = T separately.