Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Code design philosophy] Software-specific configuration files and abstractions #88

Open
ligerzero-ai opened this issue Oct 4, 2024 · 0 comments

Comments

@ligerzero-ai
Copy link
Contributor

Motivation for making the issue/discussion: There was a suggestion to use some kind of centralised resource management abstraction via ResourceResolvers from pyiron_snippets.

We need to decide how configs for resource paths and the like should work in pyiron_workflow node libraries... I would strongly prefer a per-software configuration in each node-module instead of centralised configuration inheritance. Most users only use 2-3 different types of software. This (to me) doesn't justify abstraction complexity to minimise code duplication.

Furthermore, there's lots of ways different software works. E.g. some software requires proprietary licenses, placed on different places, with other resources elsewhere. You can't just place these in a "pyiron_resources" folder.

I make this comment because while attempting to minimise code duplication is tempting via abstractions, consider:

# Initialize the resource resolver
resource_paths = [str(Path.home().joinpath("pyiron-resources-cmmc"))]
module = "vasp"
subdirs = ["potentials"]

resolver = ResourceResolver(resource_paths, module, *subdirs)

# Define the file pattern to search for
search_patterns = ["potentials_vasp.csv"]

# Perform the search
    potcar_df= pd.read_csv(resolver.first(search_patterns))

versus:

potcar_library_path = read_potcar_library_path(vasp_config_file)
potcar_df = pd.read_csv(potcar_library_path+"potentials_vasp.csv")

The config file probably looks extremely different for different types of code (plugins for abacus/ansys, potentials for lammps, etc.).
ResourceResolver doesn't solve anything in this case, and obfuscates, minimises readability by a lot.

I guess my point is that it is far simpler to let users generate their software-specific configuration files. A centralised abstraction does not make sense here. After all, the users of the software know best how they would prefer software specific resources set up. If we use centralised resource configuration, the pyiron_nodes risk running into the same problem (in my view) experienced by many external users wrt. normal pyiron; expectation of conformity to how we expect people to do things (e.g. job run cycle etc.) vs. the many different ways everyone else does things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant