Input external temperature matrix

[Scottmar93]

Summary
Allow for an external temperature matrix T(x,y,z) (and a potetial boundary conditions phi(y,z)) and output an internal heat generation matrix.

[valentinsulzer]

is this similar to what @rtimms and @TomTranter added in #543 ?

[Scottmar93]

Should be able to use much of that functionality. However, was going to look into allowing T(x, y, z) to be fed in without adding dT/dt=0 (at least for KLU)

[TomTranter]

Yeah this is basically what we're doing for 1+1. Would be great to have a solution that works for all cases. We can discuss at next meeting

[rtimms]

I was thinking about this and might be useful/user friendly to have a dict model.external_variables (or some other name) where you can set/update any variable you like either from another simulation or data etc. might also be useful for testing and prototyping (e.g. you might know what the solution looks like if you fix one variable to be 1). not sure of the cleanest way to set this up, as it would be good to have access to this variable between steps of the solver so you can update it, but the way it is currently implemented (d/dt of that var) is a bit rough and ready. If the variable just lives as some array in the expression tree it might be hard to access after you simplify the model. I guess this could be fixed by having a special node which is an array that doesn't get simplified out?

[valentinsulzer]

Yeah I think that's a better way of doing it. This ties in to having inputs for parameter fitting. A good way of doing it might be defining models as normal, but having a new node InputParameter (and maybe also, InputVariable so those can get discretised?), and then in the parameter values we convert some of the parameters to input parameters instead of scalars.

Then, either we can have an update_inputs step, or we can provide a vector u alongside t and y which gets read by input parameters.

Input parameters get treated as "not constant" so they aren't simplified out. This is also exactly what casadi does so would be easy to convert to their format (this may inform & enforce one or the other choice of how we update inputs)

[Scottmar93]

I like the idea of just providing an additional vector u. We can then just use the stuff we have for y_slices to interact with it. I'm not sure what the interfaces on other solvers are like for doing this with a variable like T(x) but I can think of a few things worth trying for KLU at least.

To be consistent with the rest of our model structure, we would add External submodels that create a T=InputVariable('Cell temperature' ) and then inherit from the base submodels so we still get easy access to all the useful outputs for that submodel. I guess you are write that the input variable would need to be discretised onto our grid with the spatial method we use. Might be nice to offer an option for interpolation onto our grid at that stage (noting that this will likely slow things down)

[valentinsulzer]

I'm hoping we can even do it without needing to add new submodels. So we just use the same model for isothermal and external, but with T=Parameter("Cell Temperature"), but then in the isothermal case we have ParameterValues({"Cell Temperature": 298} and in the external case ParameterValues({"Cell Temperature": "[input]"}) and then another dictionary with the inputs. Or something like that. Pretty sure it would work for scalar parameters but temperature might be harder because of all the different submodels?