Usability enhancements for expression based BC's and utilities
Functionality to add/problem to solve
The functionality of the expression-based tools is handy for some basic things and it has the potential to be a really powerful addition to OF, but I've run in to multiple issues relating to accessing other fields after only a little bit of playing (other than the bug I reported in issue #2012 (closed) ):
- The setExpr(Boundary)Fields tools do not automatically load fields referenced in the equations, only the field(s) being manipulated. There are workarounds of course (the readFields FO for example) but this is not ideal and is different from the functionality of funkySet(Boundary)Fields.
- A similar issue arises when using an expression as a BC for one field that relies on data from another field. My use case was calculate the exiting temperature at an outlet, based on an assumed heat flux and the temperature/flow rate at the inlet. So my T boundary conditions needed to know phi.
- The first challenge was the fact that the order in which the solver reads the fields now matters (i.e. if phi is read before T, then everything works; but if T is read into the solver before phi is loaded, the expression BC throws an error because phi doesn't exist yet). I was able to work around that in my test case by just reordering the reading of the fields in my solver, but this is obviously not a general fix.
- I then ran into a similar issue when trying to decompose my case. (decomposePar decomposed T before phi and failed). This ended up being a kind of fatal issue because the readFields FO doesn't work with decomposePar. I suppose the other other workaround would be to change the expression to the point that it decomposes, then change the expression in each processor folder after...
Target audience
Fixing these two issues will make the expressions a lot more powerful and useful for cases like the one I described above where we can model heat exchange in a relatively simple way. I could also see uses for it in transient cases where you would want to 'control' windows or fans or something as a function of temperature or scalar concentration (i.e. fires).
Proposal
Item 1 is the more straightforward of the two to fix. The easiest would be including an optional fieldsToLoad parameter to the utilities which would read in a list of field names the utilities need to know about. A second, cleaner option would be to do a first pass with the parser to pick off all the field names and then load them into memory.
Item 2 is trickier. I've done some BC coding but I'm not really sure where you would start with this. A simple fix could be to just have decomposePar ignore expression fields. I'm not sure if there is anything more sophisticated to do beyond that. Perhaps some inspiration from groovyBC?
What does success look like, and how can we measure that?
Success would be the issues I noted above not occuring to allow more flexibility with the expressions.
Links / references
N/A
Funding
I would imagine that similar functionality could be found in the funkySetFields/groovyBC libraries.