[FEA] Expose solver parameter enumeration and config-file round-trip through the C API

[ramakrishnap-nv]

Is your feature request related to a problem? Please describe.

Python can enumerate solver parameters and round-trip them through a config file. The C API cannot, so no C-ABI binding can either.

PR #1524 briefly added four entry points for this, promoted from a private shim in the Java bindings:

• cuOptGetNumSolverParameters(cuopt_int_t*)
• cuOptGetSolverParameterName(cuopt_int_t index, cuopt_int_t size, char* name)
• cuOptLoadParametersFromFile(cuOptSolverSettings, const char* path)
• cuOptDumpParametersToFile(cuOptSolverSettings, const char* path, cuopt_int_t hyperparameters_only, cuopt_int_t* dumped)

They were removed again before merge. They are convenience rather than necessity — nothing needs them to build, solve, or read a solution — and the preference was to keep the public C API lean. Filing this so the capability is recorded rather than lost, and so there is somewhere to point if a user asks.

Describe the solution you'd like

If this is revisited, the pieces are independent and can land separately:

Parameter enumeration — cuOptGetNumSolverParameters plus cuOptGetSolverParameterName, backed by solver_settings_t::get_parameter_names(), which already exists. This is what lets a binding present the full parameter list without hard-coding it, and what backed Java's SolverSettings.getSolverSettingNames() and toDict().

Config file round-trip — cuOptLoadParametersFromFile and cuOptDumpParametersToFile, backed by the existing load_parameters_from_file / dump_parameters_to_file.

Two notes for whoever picks this up:

1. Do not expose the hyperparameters flag. The original cuOptDumpParametersToFile took a hyperparameters_only argument. Parameters are marked as hyperparameters precisely so they are not broadly advertised, so a public entry point should not name the concept. Dump the non-hyperparameter set unconditionally.
2. The dump output is a template, not a snapshot. dump_parameters_to_file writes every parameter commented out (# name = value) as a starting point for the user to edit. Feeding it straight back to the loader therefore changes nothing, which is easy to mistake for a bug. The loader accepts name = value lines and ignores blanks and # comments.

Describe alternatives you've considered

• Leave it out. Current state. Callers set parameters by name using the constants in constants.h, which the Java bindings surface through the generated CuOptConstants class. This covers the common case; what is lost is discovering the parameter set at runtime and persisting a configuration.
• Expose the parameter list as a string-array attribute rather than an index-and-name pair. Would fit the attribute model better, but needs a settings-scoped attribute accessor, which does not exist.

Additional context

Removed in #1524 following review; see the discussion there. Related: #1202 (solver statistics, now exposed as solution attributes) and #1703 (problem-model accessors).

[mlubin]

Are you sure we need runtime introspection into the list of parameters? Parameters are defined in C at https://github.com/NVIDIA/cuopt/blob/6f164aec06d00b88488be9014e03885066330773/cpp/include/cuopt/mathematical_optimization/constants.h and C-ABI bindings can be generated from that source.

[ramakrishnap-nv]

@mlubin you're right, and it's stronger than "can be generated" — the runtime list is derived from that header, so it cannot contain anything the header doesn't.

I checked the registration table in cpp/src/math_optimization/solver_settings.cu, which is what get_parameter_names() returns:

• 117 parameter registrations, every one of them written as a CUOPT_* macro. Not a single raw string literal.
• Comparing the 109 distinct registered names against the string constants in constants.h: zero are registered without being declared in the header.

So a binding generated from constants.h has the complete set by construction, and runtime enumeration cannot tell it anything new. That was the only real justification for cuOptGetNumSolverParameters / cuOptGetSolverParameterName, so I'll drop that half.

Following the same reasoning, the config-file half doesn't need to be in the C API either. A binding can implement both directions on top of what already exists: parse name = value and call cuOptSetParameter to load; iterate the generated name list calling cuOptGetParameter to dump. Neither needs new C surface.

The only argument I can see for owning it in the C API is format compatibility — so a config written by cuopt_cli loads in a Java or Go binding without each one reinventing the format. That seems weak enough not to hold the issue open; happy to be told otherwise.

Closing this. If the format-compatibility point turns out to matter, it's easy to reopen.

---

One thing the comparison turned up, in the opposite direction. CUOPT_MIP_PRESOLVE ("mip_presolve") is declared in constants.h but registered nowhere and referenced nowhere else in the tree:

cpp/include/cuopt/mathematical_optimization/constants.h:66:#define CUOPT_MIP_PRESOLVE  "mip_presolve"

Since bindings are generated from that header, they advertise a parameter that cuOptSetParameter will reject. It reaches Java today through the generated CuOptConstants. Worth either registering or removing — I can file it separately if it isn't already known.