State features: fill and data dimensions support.

[FlorianDeconinck]

Continuing the feature set for State as we met them.

• Introduce a fill method that will fill all fields with a particular value
• Allow for field to be used easily with data dimensions via a temporary Sizer swap

Side task:

• Clean up a global_config that isn't used anymore.

[FlorianDeconinck]

Note for reviewer:

The sizer swap is an inelegant solution to a mismatch in QuantityFactory design and real use.

By design QuantityFactory is a self-contained factory that requires a precise description of the system (e.g. Sizer, dims to allocate). But the use of it is that most of the time you have a firm "Grid" definition with the cartesian space well defined, and data dimensions wildly changing per code. You could, in theory, define a QuantityFactory with every single dimensions and then call it with the one that make sense. You can't force this level of coherency on a model. Hence the mix: swap the sizer on call, when you know, and reuse the Grid space.

[romanc]

Can we move the unrelated changes to global_config.py out into a separate PR?

Regarding the ddims swap on the sizer: I think it's quite elegant since (from the front) nobody sees that we are doing behind the scenes. Have you considered making data_dimensions completely optional, e.g.

@classmethod
def empty(
    cls,
    quantity_factory: QuantityFactory,
    *,
    data_dimensions: dict[str, int] | None = None,
) -> Self:
    """Allocate all quantities. Do not expect 0 on values, values are random.

    Args:
        quantity_factory: Quantities are allocated with this factory.
        data_dimensions: If provided, overrides the data dimensions of
            `quantity_factory`. Dict of name/size pairs or `None` (default).
    """

    if data_dimensions is None:
        return cls._init(quantity_factory.empty)

    with State._FactorySwapDimensionsDefinitions(quantity_factory, data_dimensions):
        return cls._init(quantity_factory.empty)

In that case, I'd suggest to force data_dimensions as a keyword argument. We could also think about renaming the argument to something like tmp_ddims, ddims_override, ...

[romanc]

Ah and I forgot to mention: would a full (as in numpy) be useful to allocation and initialize to any given number (not just 0 and 1)?

Edit: Reminds me of issue #166.

[fmalatino]

Approve pending requested changes by other reviewers.

[FlorianDeconinck]

• Added full - just on State, will do Quantity in another PR
• Re: naming of data dimensions parameter

I am eager to keep data_dimensions as a name to describe the use rather than something that would hint at the implementation. Users tend to not really concern themselves with how data dimensions are carried by quantity factory, I'd rather keep straighforward. If it's confusing people, let's change

[romanc]

🚀