[tbuchanan2]

Hi,

I was trying to figure out how to replicate numpy's einstein's summation (NumPy.einsum) in Openfoam and was wondering if any packages have been made.

[olesen]

Originally Posted by tbuchanan2

Hi,

I was trying to figure out how to replicate numpy's einstein's summation (NumPy.einsum) in Openfoam and was wondering if any packages have been made.

After searching what numpy is actually doing there, the short (and longer) answer is "no, nothing like that in OpenFOAM".


To make that answer easier to accept, you need to be specific about what you are actually trying to achieve. Lets assume for the moment that this functionality would be really flexible and useful, you have the initial problem that everything in C++ (OpenFOAM) is strongly typed.
Consider an operation between two vectors: the inner product and outer product return different types. For numpy, these types can be "boxed" into the same object with the internals being something different. If you want this in OpenFOAM, you need a boxed representation as well and carry that through in various different places. If we extend that from a single vector/vector operation to a field (1D list) of vector/vector operations, the boxing would be at the top list level, not for each individual element.
So far, still seems doable (with a fair bit of coding). However, if we now want something actually useful, we should be talking about volVectorField etc. If these are to somehow be represented as boxed values, I have absolutely no idea what the boundary conditions should look like. Everything "calculated" or "zeroGradient"? Nothing else really makes sense. Processor-processor interfaces would also be highly interesting too.


If, on the other hand, you are interested in defining something that would be more "scripting", could think of extending or replacing the current "expressions" handling accordingly, but these are more of a domain-specific language rather than proper C++ OpenFOAM intrinsics.


Take a look at some of the expression handling in OpenFOAM. The lexing part is done with Ragel, the parser is written in Lemon, but expressed in more abstract rules with an m4 layer to allow reuse for different geometric types. Initially it may look a bit confusing, but IMO is actually a pretty solid combination. This is where you should be looking for squirreling in your additional einstein notation.
With the expressions handling, we have almost exactly the same situation of using boxed field representations.