Closed arporter closed 8 years ago
Created new branch support_mult_operand for this issue.
Actual fix was straightforward - just had to recurse down if we encounter a Mult_Operand object.
"**" was not a recognised operator so I've added it to the ivy-bridge config file.
On reflection, it is not really an operator - more an intrinsic. If this was C code for instance we'd have a call to the pow()
routine. It's just that the Fortran compiler generates the appropriate call for us.
I'll change it to be defined as an intrinsic and extend my micro benchmarks to estimate a cost for it...
While reviewing test coverage of the code modifications I realised I could add a test for the exception we raise when we don't recognise the object produced by the parser. All modified code is covered by the test suite.
Branch support_mult_operand merged back onto master. Closing issue.
Processing the named dynamo source file fails with:
dag_node.DAGError: "DAG Error: Unrecognised child type: <class 'fparser.Fortran2003.Mult_Operand'>, (temp1 * rho_ref_at_quad(i) * theta_ref_at_quad(i)) ** temp2"
This is because in #3 I changed the code to no-longer silently skip any parser-generated object that it didn't recognise.