`solver.settings.setup.materials.database` behaves like a TUI object, not a proper settings API object

[seanpearsonuk]

📌 Issue: solver.settings.setup.materials.database behaves like a TUI object, not a proper settings API object

Summary

The current implementation of solver.settings.setup.materials.database does not conform to the expected behavior and design goals of the PyFluent settings API. Instead of being a well-structured, introspectable object, it behaves like a thin wrapper over the TUI interface. This limits its usefulness for scripting, automation, and integration with tools like LLMs or GUI builders.

Observations

❌ No meaningful structure exposed

db.child_names
# ['database_type']

db.query_names
# []

There is no way to query available materials, property groups, or other useful sub-objects.

❌ Exposes legacy-style commands directly

db.command_names
# ['copy_by_formula', 'copy_by_name', 'list_materials', 'list_properties']

• list_materials() returns None and prints to stdout — not usable in a programmatic context.

• list_properties(name="tetracarbon") behaves similarly — dumps a formatted string instead of structured data.

❌ Results are not structured

mats = db.list_materials()
# None — output goes to console, not to a usable object

props = db.list_properties(name="tetracarbon")
# None — again, printed, not returned

These violate the expectations for the settings API, where methods should return data that can be consumed, inspected, or transformed.

Why This Matters

This interface breaks the consistency and integrity of the settings API, which is designed around:

• Navigable, introspectable objects – users should be able to explore what's available using .child_names and .query_names.
• Structured return values – methods should return data (e.g. lists, dictionaries, or structured objects), not just print to stdout.
• Minimal exposure to TUI-style commands – commands like list_materials() are procedural and not aligned with object-based settings access.
• Composable access – the API should enable users to programmatically build and manipulate workflows, which isn’t possible with print-only results.

Without addressing this, the materials.database object will continue to:

• Confuse users expecting parity with other parts of the settings API
• Undermine automation use cases
• Limit the ability to support AI and GUI integrations that rely on consistent, machine-readable structure

[dnwillia-work]

Having used this API in the past I've got to agree with the general feedback. It's pretty unusable the way it is.