Fparser app

[roystgnr]

This has been invaluable for boiling down problems with fparser strings.

I'm about to see if it's also useful for hunting down a bug (regression?) in fparser itself - try running "fparser_parse-dbg 'b := 1/abs(x); if(b<=1000,b,10)' 1"...

[moosebuild]

Results of testing de5cbc2 using libmesh_PR_test recipe:

Passed on: linux-gnu

View the results here: https://www.moosebuild.com/view_job/6106

[roystgnr]

That fparser line works fine with a --disable-fparser-optimizer build.

[moosebuild]

Results of testing de5cbc2 using libmesh_PR_test_dbg recipe:

Passed on: linux-gnu

View the results here: https://www.moosebuild.com/view_job/6107

[jwpeterson]

@dschwen

[dschwen]

Huh?

[jwpeterson]

Huh?

Would you care to comment on some of the fparser optimizer debugging methods you've developed over time?

[dschwen]

I had to look at ParsedFunction again to see how much of the new FParserAD stuff it supports. It might be worthwhile to add a call to gradient() to that app and output that as well. And while you're at it add a range/step parameter. That way the app could be used for quick tabulation, or writing tests.

Maybe I should add an interface to ParsedFunction to perform the just in time compilation. That functionality is not exposed by ParsedFunction yet. It could be added to this app (optional) as well. That way the app could be used to populate the JIT cache on systems that do not provide compilers on compute nodes.

[roystgnr]

How hard would it be to add JIT support to ParsedFunction? I'm currently between a rock and a hard place; runs with --disable-fparser-optimizer are intolerably slow for our app, runs with the default configuration give grossly wrong results under some conditions.

[roystgnr]

This doesn't look like an easy-to-bisect regression, either - I get the same failure when backporting this PR onto f58d4a4...

[dschwen]

Adding jit support would be as easy as adding a compile() member that invokes the jitcompile method on the contained fparser object. But I guess I don't understand what the regression is yet.

[roystgnr]

The command I listed above should obviously return 1, and if you make slight simplifications (get rid of the abs() call or the inversion) it does; instead it returns 10.

[dschwen]

Ok, I realized that in the mean time and I'm building a little test program to look at the bytecode before and after optimization. I have a suspicion that it may be related to optimizer rules regarding 'guaranteed positivity' (which is set by the abs function). Let me check.

[dschwen]

Nice.... this is what my thingie spits out:

Input Expression:
b := 1/abs(x); if(b<=1000,b,10)
Size of stack: 3
0000: push Var0     = [0]x
0001: abs           = [0]abs(x)
0002: inv           = [0]abs(x)^-1
0003: dup           = [1]abs(x)^-1
0004: push 1000     = [2]1000
0005: le            = [1]le(abs(x)^-1,1000)
0006: jz_abs 1,000d = (void)
0009: dup           = [1]abs(x)^-1
000a: jump 2,000e   = (void)
000d: push 10       = [1]10
000e: ----- (phi)   = [1]if(le(abs(x)^-1,1000),abs(x)^-1,10)

f(1) = 1

Optimized Input Expression:
b := 1/abs(x); if(b<=1000,b,10)
Size of stack: 1
0000: push 10       = [0]10

f(1) = 10

The FPOptimizer is waaay overeager here and optimizes the program down to a constant. I will investigate further.

[jwpeterson]

On Wed, Oct 1, 2014 at 1:06 PM, Daniel Schwen notifications@github.com
wrote:

Nice.... tjis is what my thingie spits out:

Input Expression:
b := 1/abs(x); if(b<=1000,b,10)
Size of stack: 3
0000: push Var0 = [0]x
0001: abs = [0]abs(x)
0002: inv = [0]abs(x)^-1
0003: dup = [1]abs(x)^-1
0004: push 1000 = [2]1000
0005: le = [1]le(abs(x)^-1,1000)
0006: jz_abs 1,000d = (void)
0009: dup = [1]abs(x)^-1
000a: jump 2,000e = (void)
000d: push 10 = [1]10
000e: ----- (phi) = [1]if(le(abs(x)^-1,1000),abs(x)^-1,10)

f(1) = 1

Optimized Input Expression:
b := 1/abs(x); if(b<=1000,b,10)
Size of stack: 1
0000: push 10 = [0]10

f(1) = 10

The FPOptimizer is waaay overeager here and optimizes the program down to
a constant. I will investigate further.

Cool, this is really good software.

John

[dschwen]

You can construct similar cases with the < operator: 1/abs(x)<1 for x==1 should evaluate to 1, but optimizes to 0. It is like the argument of the < and <= operators are ignored and assumed to be 0.

[jwpeterson]

@roystgnr may also get a kick out of idaholab/moose#1923

[roystgnr]

No luck switching to JIT. Here's the code generated:

#define _USE_MATH_DEFINES
#include <cmath>
extern "C" double f_c3da290ffb3d00003aa5165348aa0c85a6852fc8(const double *params, const double *immed, const double eps) {
double r, s[2];
s[0] = params[0];
s[0] = std::abs(s[0]);
s[0] = 1.0/s[0];
s[1] = immed[0];
s[0] = s[0] < (s[1] - eps);
if (s[0] < 0.5) goto l12;
s[0] = params[0];
return s[0]; }
l12:
s[0] = immed[1];
return s[0]; }

Which obviously causes the compiler to scream and run away from the screwy braces.

[dschwen]

Oh, yep. I see exactly where this bug is in the code. One sec...

[permcody]

In my experience "One sec" usually equates to one bug fixed, one new bug
introduced...

Hold onto your butts!

On Wed, Oct 1, 2014 at 2:50 PM, Daniel Schwen notifications@github.com
wrote:

Oh, yep. I see exactly where this bug is in the code. One sec...

—
Reply to this email directly or view it on GitHub
#366 (comment).

[jwpeterson]

On Wed, Oct 1, 2014 at 3:10 PM, Cody Permann notifications@github.com
wrote:

In my experience "One sec" usually equates to one bug fixed, one new bug
introduced...

Hold onto your butts!

Heheh. It was a one character change, hopefully it doesn't break anything
else.

John

[dschwen]

It was a pretty obvious mistake (that should have been spotted during code review, I mean.. come on guys! ;-) )

[jwpeterson]

On Wed, Oct 1, 2014 at 3:13 PM, Daniel Schwen notifications@github.com
wrote:

It was a pretty obvious mistake (that should have been spotted during code
review, I mean.. come on guys! ;-) )

I blame poor test coverage.

John

[roystgnr]

We ought to use this app to make a big "fparser test script" eventually. First we'd want to expose decisions like whether to call Optimize() and/or JITCompile() at run-time rather than at configure-time (or as in my current JIT test builds, at "roy just changes parsed_function.h and sees if it works"-time).

[jwpeterson]

Seems more like a CPPUNIT test to me.

[roystgnr]

@dschwen, another JIT bug with a 1 char fix: you've got atan2 calls getting converted to atan calls.

[dschwen]

Thx, @roystgnr will fix that in a minute.

[dschwen]

Coming back to the original issue. I think I'm zeroing in. The culprit is a faulty result boundary calculation. FParser seems to think that the minimum possible value for 1/abs(x) is inf :-/