uw.Params silently ignores negative CLI values (-uw_x -1 falls back to the default)

[lmoresi]

uw.Params reads CLI overrides from the PETSc options database, which treats a leading '-' token as an option name. So a negative value is never delivered: -uw_sense -1 registers 'sense' with an EMPTY value and '1' as an unrelated option; -uw_sense=-1 is not recognised at all. Params then falls back to the default silently.

Probe (uw.Params(sense=uw.Param(1.0, ...)); print float(p.sense), uw.options.getString('sense', '')):

argv	p.sense	raw PETSc string
-uw_sense 2	2.0	'2'
-uw_sense -2	1.0	''
-uw_sense -0.5	1.0	''
-uw_sense=-2	1.0

Consequence: half of a 26-run parameter ladder (sense = -1, the releasing-bend drive) ran at the default +1 and reported under the requested label — only caught because the partition numbers were identical to the +1 runs.

Suggested fix, two layers: (1) Params raises when an option is present with an empty value rather than using the default (the silent part is the dangerous part); (2) accept a quoting form for negatives (PETSc accepts -opt -1 when the next token parses as a number in some paths; if not, document -uw_x=-1 or a '--' style). Workaround used here: a boolean switch param (releasing=1) mapped to the sign in the script.

Underworld development team with AI support from Claude Code

[lmoresi]

Confirmed still live, and a warning about the suggested fix: the first layer as proposed would raise on ordinary positive overrides, at least on this environment. I implemented it, tested it, and backed it out.

What reproduces

-uw_sense -2 gives the default silently — p.uw_sense = 1.0. That part is exactly as reported.

What is different here, and why it matters

On this stack (macOS/arm64, PETSc 3.25.0) the option ends up registered with an empty value for both signs:

argv	hasName('sense')	getString('sense', SENTINEL)	p.uw_sense
-uw_sense 2	True	SENTINEL (i.e. empty)	1.0 (default)
-uw_sense -2	True	SENTINEL (i.e. empty)	1.0 (default)

So the positive case fails here too, where this issue's table has -uw_sense 2 → 2.0 with raw '2'. The CLI override path is broken more broadly on this environment than the issue describes — the value never arrives at all, whatever the sign.

The consequence for the proposed fix is direct. Layer (1) is "Params raises when an option is present with an empty value rather than using the default". Here -uw_sense 2 is present with an empty value, so that guard fires on a perfectly ordinary positive override and turns a working script into an exception. I had it written and passing its own probe before this showed up; reverted unshipped.

What I think the actual first step is

Find why parse_cmd_line_options() leaves the name registered with an empty value. Until that is understood, "present but empty" cannot be used as the signal for "a negative was eaten", because on at least one environment it is also the signal for "a positive arrived fine". Layer (2) — accepting an explicit quoting form — is unaffected by this and is probably the safer thing to do first, but note that -uw_sense=-2 did not work here either.

Worth someone re-running the table in this issue on Gadi and on Linux/CI, since the two environments evidently disagree about what the options database ends up holding.

Underworld development team with AI support from Claude Code

[lmoresi]

Two follow-ups: an answer to whether this is type-sensitive, and a second silent-default path found while checking.

It is the sign, not the type

Measured at the options-database level, after parse_cmd_line_options():

argv	getString	getReal	getInt
-uw_sense 2	'2'	2.0	2
-uw_sense -2	''	default	default
-uw_sense 2.5	'2.5'	2.5	raises
-uw_sense -2.5	''	default	default

-2 and -2.5 fail identically and 2 and 2.5 both work, so the negative-value defect is not int-versus-float. This reproduces the issue's original table exactly. (My earlier comment on this issue reported the positive case failing too — that was wrong, and caused by a bug in my own probe's output formatting, not by the code. Please disregard that part; the rest of that comment, about the proposed guard, still stands and is now better supported.)

The second path: getInt raises on a float value, and a bare except hides it

getInt("sense") on a value of 2.5 raises rather than returning the default. In _params.py::_get_petsc_option, the legacy (non-Param) branch is:

match default:
    case int():   return opts.getInt(name, default)
    ...
except:
    return default          # bare except

So declaring uw.Params(uw_steps=3) and passing -uw_steps 2.5 raises inside getInt, is swallowed by the bare except, and silently returns 3. Same consequence as this issue — a run that reports one configuration and executes another — reached by a different route, and it needs no negative sign to trigger.

That one has an unambiguous fix, unlike the empty-value guard: an int-typed parameter given a non-integer value should raise with the offending value named, not fall back. The bare except should also be narrowed — as written it hides any error from the type-dispatch block, not just this one.

Caveat on scope

These results are all at the options-database level, which was stable and repeatable. My attempts to characterise the same thing through uw.Params were not stable across runs and I could not pin down why, so I am deliberately not reporting Params-level numbers here. Anyone fixing this should re-derive them rather than trust a Params-level probe.

Underworld development team with AI support from Claude Code