-
Notifications
You must be signed in to change notification settings - Fork 152
SimultaneousSolutions
We've encountered some situations in our own research lately that benefit substantially from simultaneous solution, e.g.,
would normally be solved with
where the `...` is ideally some `ConvectionTerm`, but which might be an explicit `(DphiT * T.getFaceGrad()).getDivergence()` and so on if w can't easily factor out the dependence of
It can be advantageous, though, to create a new master variable
Daniel presently has a functional (but arguably brutish) implementation of this, but we've been brainstorming a way to make this more general and more elegant. The idea that we are currently playing with is to use the `()` method of a `Term` to change it from a generic operator like it is now into an operator applied to a specific `CellVariable`, i.e.
* The current syntax will remain valid. `DiffusionTerm(coeff=D)` will continue to represent $\nabla\cdot (D \nabla)$. You must call `solve(var=phi)` or `sweep(var=phi)` to apply the operator to the variable $\phi$. * If, instead, you write `DiffusionTerm(coeff=D)(phi)`, this will represent $\nabla\cdot (D \nabla \phi)$. There will be no need to pass a variable to `sweep()` or `solve()`. In fact, it might be an error to do so.
In this new syntax, we would write
and then call `solve()`, either without a `var` argument, or perhaps with a `var` argument that must only contain a tuple of `phi` and `T`. I'm inclined to prohibit the `var` argument, because the list of solution variables is already implicitly determined by the `Term`s, so its value is proscribed.
It should also be possible (and maybe a bit clearer) to write
We had originally talked about writing `eq = eq_phi & eq_T`, but as I write this up, I now don't think there's any reason to introduce this new syntax.
There remains an issue of what to do about boundary conditions.
* One option is to make boundary conditions also take a `__call__()` method, so `FixedValue(...)` would apply to whatever variable was passed to `eq.solve(var=...)`, but `FixedValue(...)(phi)` would explicitly mean $\phi|_\text{some boundary} = \text{some value}$. * Another option is to wait for our planned boundary condition reform and to require all boundary conditions to either be applied directly to `CellVariable`s or to be incorporated as `SourceTerm`s in the equation, as discussed in the new FAQ.
We welcome suggestions of how users would like this to look and behave.