Settings API improvement suggestion

[h-krishnan]

At present, the option to set a value via the settings API is via attribute assignment:
setup.models.energy.enabled = True
This is not amenable to chaining.
We could support the following additional syntax:
setup.models.energy.enabled(True)
This could return the parent object and so one could do something like:
setup.models.energy.enabled(True).viscous_dissipation(False)
results.graphics.contour.create('c1').field('velocity-magnitude').surfaces_list(['wall1', 'wall2']).display().

[ Will this be a bit confusing when supported at Group/NamedObject level, because the parent object is being returned?
setup.models.energy({'enabled' : True}).viscous({'model' : 'k-epsilon'}) ]

We can support keyword-based assignment for container objects:
setup.models.energy(enabled = True, viscous_dissipation = False)

[h-krishnan]

Another option: return the same object instead of the parent object.
In this case, for chaining methods, users will have to set values at the parent level.

setup.models.energy(enabled=True)
This could return back the object and so one could do something like:
setup.models.energy(enabled=True)(viscous_dissipation=False)
results.graphics.contour.create('c1')(field = 'velocity-magnitude')(surfaces_list = ['wall1', 'wall2']).display().

Multiple keywords may also be specified:
results.graphics.contour.create('c1')(field = 'velocity-magnitude', surfaces_list = ['wall1', 'wall2']).display().

For primitive types:
setup.models.energy.enabled(True)
This will return enabled object and so chaining is not possible unless one uses the parent attribute.

[seanpearsonuk]

@h-krishnan thanks for opening this topic

Whatever we do needs to follow the principle of least astonishment. Obviously nothing surprising about the current assignment syntax. Any new syntax style should be something that's obvious, natural and ideally used across PyAnsys/Ansys. As we know, OnScale has its own niche syntax. If every other product/library comes up with something new and different, that won't be good for users. Even if it's something uniform across PyAnsys/Ansys (say adopted from OnScale) but different from ordinary Python patterns, that's still potentially an issue.

One question about chained assignments is: when does the state get sent to the server? There's nothing in

setup.models.energy(enabled=True)(viscous_dissipation=False)

to say 'done' so each setting would be sent individually. If changing many remote settings, we might want a simple syntax that allows the user to express when they're done and wants to send all the settings.

A simple approach might be not to think about chaining and just to pass keyword arguments in a single call:

setup.models.energy(enabled=True, viscous_dissipation=False)

or if we should be more explicit about the operations, something like:

setup.models.energy.set_state(enabled=True, viscous_dissipation=False)

[seanpearsonuk]

@h-krishnan
I see that you also mentioned the keyword approach

[dnwillia-work]

This seems like a useful idea to make things a bit more compact.

[seanpearsonuk]

This is the main capability to try to add

setup.models.energy.set_state(enabled=True, viscous_dissipation=False)

once that is done, adding the following could be relatively easy, but let's omit it from the initial work:

setup.models.energy(enabled=True, viscous_dissipation=False)

The code is in flobject.py. See set_state.

Take a look at this unit test:

def test_group():
    r = flobject.get_root(Proxy())
    r.g_1 = {"r_1": 3.2, "i_2": -3, "b_3": False, "s_4": "foo"}
    assert r.g_1() == {"r_1": 3.2, "i_2": -3, "b_3": False, "s_4": "foo"}
    r.g_1 = {"s_4": "bar"}
    assert r.g_1() == {"r_1": 3.2, "i_2": -3, "b_3": False, "s_4": "bar"}
    r.g_1.i_2 = 4
    assert r.g_1() == {"r_1": 3.2, "i_2": 4, "b_3": False, "s_4": "bar"}
    return True

Those assignments like r.g_1 = {"r_1": 3.2, "i_2": -3, "b_3": False, "s_4": "foo"} are going through set_state (in flobject.py). So one could actually add equivalent tests there that call set_state directly instead of direct assignment. Then, with those new tests in place, one can write a test that calls r.g_1.set_state(r_1=3.2, i_2=-3, b_3=False, s_4="foo") which, with the necessary changes in place in flobject.py, will produced the same result.