Module Sundials_NonlinearSolver.Custom

module Custom: sig .. end

Custom nonlinear solvers.


val make : ?init:(unit -> unit) ->
?setup:('d -> 's -> unit) ->
?set_lsetup_fn:('s Sundials_NonlinearSolver.lsetupfn -> unit) ->
?set_lsolve_fn:((('d, 'k) Nvector.t, 's) Sundials_NonlinearSolver.lsolvefn ->
unit) ->
?set_convtest_fn:(('d, 's, [ `Nvec ]) Sundials_NonlinearSolver.convtestfn ->
unit) ->
?set_max_iters:(int -> unit) ->
?set_info_file:(Sundials.Logfile.t -> unit) ->
?set_print_level:(int -> unit) ->
?get_num_iters:(unit -> int) ->
?get_cur_iter:(unit -> int) ->
?get_num_conv_fails:(unit -> int) ->
nls_type:Sundials_NonlinearSolver.nonlinear_solver_type ->
solve:('d -> 'd -> 'd -> float -> bool -> 's -> unit) ->
set_sys_fn:((('d, 'k) Nvector.t, 's) Sundials_NonlinearSolver.sysfn -> unit) ->
?context:Sundials.Context.t ->
unit -> ('d, 'k, 's, [ `Nvec ]) Sundials_NonlinearSolver.t

Create a nonlinear solver from a set of callback functions.

The callbacks should indicate failure by raising an exception (preferably one of the exceptions in this package). Raising Sundials.RecoverableFailure indicates a generic recoverable failure.

The expected operations are:

Note that the setup and solve functions are passed the payload data directly, whereas the lsolvefn and sysfns require the data to be wrapped in an nvector. This asymmetry is awkward but, unfortunately, unavoidable given the implementation of nvectors and the different constraints for C-to-OCaml calls and OCaml-to-C calls.

val make_sens : ?init:(unit -> unit) ->
?setup:(('d, 'k) Sundials_NonlinearSolver.Senswrapper.t -> 's -> unit) ->
?set_lsetup_fn:('s Sundials_NonlinearSolver.lsetupfn -> unit) ->
?set_lsolve_fn:((('d, 'k) Sundials_NonlinearSolver.Senswrapper.t, 's)
Sundials_NonlinearSolver.lsolvefn -> unit) ->
?set_convtest_fn:((('d, 'k) Sundials_NonlinearSolver.Senswrapper.t, 's,
[ `Sens ])
Sundials_NonlinearSolver.convtestfn -> unit) ->
?set_max_iters:(int -> unit) ->
?set_info_file:(Sundials.Logfile.t -> unit) ->
?set_print_level:(int -> unit) ->
?get_num_iters:(unit -> int) ->
?get_cur_iter:(unit -> int) ->
?get_num_conv_fails:(unit -> int) ->
nls_type:Sundials_NonlinearSolver.nonlinear_solver_type ->
solve:(('d, 'k) Sundials_NonlinearSolver.Senswrapper.t ->
('d, 'k) Sundials_NonlinearSolver.Senswrapper.t ->
('d, 'k) Sundials_NonlinearSolver.Senswrapper.t ->
float -> bool -> 's -> unit) ->
set_sys_fn:((('d, 'k) Sundials_NonlinearSolver.Senswrapper.t, 's)
Sundials_NonlinearSolver.sysfn -> unit) ->
?context:Sundials.Context.t ->
unit -> ('d, 'k, 's, [ `Sens ]) Sundials_NonlinearSolver.t

Create a nonlinear solver from a set of callback functions for sensitivity problems that pass arrays of nvectors. As for the Sundials_NonlinearSolver.Custom.make function except that the callbacks receive arrays of values.

Writing custom nonlinear solvers for use with some forward sensitivity methods requires the "internal" senswrapper type. Any attempt to use Sundials_NonlinearSolver.Senswrapper.ts outside of the call to setup or solve that provides them will result in an Sundials_NonlinearSolver.IncorrectUse exception. They must only be used to extract the underlying data with Sundials_NonlinearSolver.Senswrapper.data or as arguments for lsolve_fn, convtest_fn, or sys_fn. There are no restrictions on the arrays extracted with Sundials_NonlinearSolver.Senswrapper.data.