VBDF fails for some networks on CPU

[adam-m-jcbs]

A table has been started to keep track of which integrators are able to integrate different networks on the CPU (space is also available for a similar table for the GPU, but isn't populated yet. We should work on the CPU before trying to work on the GPU anyway).

This issue addresses VBDF failures on the CPU. As the table shows, VBDF fails for the aprox13 and aprox19 networks using the configuration and input found in the unit test.

I'm currently comparing the integration of VBDF with VODE, which in theory implement the same algorithms. For aprox19 I've isolated the cell that fails for VBDF, which VODE seems fine with. I'm currently working to find where the algorithms deviate such that VODE is able to converge to a result while VBDF is not.

[zingale]

note: VBDF works for aprox13 in the nomolar branch

[adam-m-jcbs]

After some deep diving into the nest of GOTO's that is VODE, I've traced the aprox19 failure to differences in how VBDF and VODE do the non-linear solve. In other words, differences between the algorithm implemented in VBDF's bdf_solve and VODE's DVNLSD. I'm not yet certain exactly what the differences are or how to modify VBDF's algorithm to converge, but wanted to note that this is where the failure is originating before moving on to figuring out how to fix it.

I've observed that VBDF's solver keeps iterating without changing the error, while VODE iterates maybe once or twice and gets down to an acceptable error. This is all for a particular cell that burns to a given temperature about halfway through the given dt = 1.0d-9 and then just sits at that temperature for the rest of the dt, implying all available fuel has been burnt.

The initial conditions for this cell are (see aprox19 to relate xn to actual species):

  burn_state_in%rho = 91028210.15130396
  burn_state_in%T   = 428847949.2954472
  burn_state_in%xn(:) = (/0.6499999989599999,      9.9999999839999996E-011, & 
                          0.2999999995199999,      4.9999999919999996E-002, &   
                          9.9999999839999996E-011, 9.9999999839999996E-011, &   
                          9.9999999839999996E-011, 9.9999999839999996E-011, & 
                          9.9999999839999996E-011, 9.9999999839999996E-011, &   
                          9.9999999839999996E-011, 9.9999999839999996E-011, &   
                          9.9999999839999996E-011, 9.9999999839999996E-011, & 
                          9.9999999839999996E-011, 9.9999999839999996E-011, &
                          9.9999999839999996E-011, 9.9999999839999996E-011, &
                          9.9999999839999996E-011 /) 

[drummerdoc]

Sounds like a Jacobian accuracy thing. Is there a difference in how the
tolerances get set that may affect the size of the numerical twiddle for
computing Jacobian entries?

Idle speculation from an outsider with no friggin idea what you're actually
doing... :)

On Fri, Nov 18, 2016 at 10:29 AM, Adam Jacobs notifications@github.com
wrote:

After some deep diving into the nest of GOTO's that is VODE, I've traced
the aprox19 failure to differences in how VBDF and VODE do the non-linear
solve. In other words, differences between the algorithm implemented in
VBDF's bdf_solve and VODE's DVNLSD. I'm not yet certain exactly what the
differences are or how to modify VBDF's algorithm to converge, but wanted
to note that this is where the failure is originating before moving on to
figuring out how to fix it.

I've observed that VBDF's solver keeps iterating without changing the
error, while VODE iterates maybe once or twice and gets down to an
acceptable error. This is all for a particular cell that burns to a given
temperature about halfway through the given dt = 1.0d-9 and then just
sits at that temperature for the rest of the dt, implying all available
fuel has been burnt.

The initial conditions for this cell are (see aprox19 to relate xn to
actual species):

burn_state_in%rho = 91028210.15130396
burn_state_in%T = 428847949.2954472
burn_state_in%xn(:) = (/0.6499999989599999, 9.9999999839999996E-011, &
0.2999999995199999, 4.9999999919999996E-002, &
9.9999999839999996E-011, 9.9999999839999996E-011, &
9.9999999839999996E-011, 9.9999999839999996E-011, &
9.9999999839999996E-011, 9.9999999839999996E-011, &
9.9999999839999996E-011, 9.9999999839999996E-011, &
9.9999999839999996E-011, 9.9999999839999996E-011, &
9.9999999839999996E-011, 9.9999999839999996E-011, &
9.9999999839999996E-011, 9.9999999839999996E-011, &
9.9999999839999996E-011 /)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZXJ0krxX42uO-JHTawQkKyT8hRlHgpks5q_e6PgaJpZM4Krf_P
.

[adam-m-jcbs]

Hey Marc! I welcome idle speculation. The Jacobian's pretty central to this solve, so I'll be careful to look for differences like those you suggest. Even at a superficial glance it looks like the Jacobian calculation (or recalculation thereof) get treated differently. I'll have to dig deeper to see exactly what's going on. It is odd that VBDF's error doesn't change at all upon iteration.

[zingale]

VODE does something fancy for the Jacobian

[drummerdoc]

The VODE I use has two options, one that calls a user-supplied routine to compute a Jacobian, and one that does something internal. We have used the former to generate an analytic or semi-analytic Jacobian. The latter uses ATOL and RTOL settings to get a small fraction of a typical value for each state. If the typical value is WAY off, the Jacobian will not be computed for those entries accurately, so some care is required.

Also, VODE’s internal J evaluator does a one-side difference for the these terms. One could also do a central difference (using the user-supplied function) for more accuracy. However, you have to be sure the twiddle in the states is of the right magnitiude. For central diffs, something around 1.d-4 of the typical value is about right. For one-sided, 1.d-7 or so tends to be better. It can be really tricky to get this right over the entire domain for all problems. It’s also really hard to find a way to prove your J is converged to a good one, without a lot of work.

On Nov 18, 2016, at 10:52 AM, Michael Zingale notifications@github.com wrote:

VODE does something fancy for the Jacobian

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #19 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABZXJ5M5rFtcakHIowI5Xl-WGbGGZHTQks5q_fP4gaJpZM4Krf_P.

[zingale]

wait... we are not using VODE's numerical Jac? I am pretty sure we did away with using our numerical Jac over VODEs.

[drummerdoc]

By “the VODE I use” I meant the one in the CCSE combustion codes. No clue what you all are using.

On Nov 18, 2016, at 11:08 AM, Michael Zingale notifications@github.com wrote:

wait... we are not using VODE's numerical Jac? I am pretty sure we did away with using our numerical Jac over VODEs.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #19 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABZXJ9YuGZrpiU8ICWfBwtyFEw9DeemTks5q_feZgaJpZM4Krf_P.

[zingale]

we've removed vbdf