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

Software-specific branching in several places should be avoided. Branching must be enveloped somehow. #205

Open
comcon1 opened this issue Dec 3, 2024 · 1 comment

Comments

@comcon1
Copy link
Contributor

comcon1 commented Dec 3, 2024

I have already seen software-specific branching in several places. At the moment the organization makes adding new software or file formats for an old software very tedious. We should think how to resolve it. In general, the good thing is to make application general - software independent via drivers, which are software specific. So, a driver - middle-layer API, should take care of all software-specific manipulations producing a standardized output, from which the following steps should be done. Then, if software specific modifications are needed, they should be done in one place, instead of introducing modifications to many different files throughout the project.

Originally posted by @pbuslaev in #201 (comment)

@comcon1
Copy link
Contributor Author

comcon1 commented Dec 3, 2024

Continue citing @pbuslaev

At the moment the organization makes adding new software or file formats for an old software very tedious. We should think how to resolve it. In general, the good thing is to make application general - software independent via drivers, which are software specific. So, a driver - middle-layer API, should take care of all software-specific manipulations producing a standardized output, from which the following steps should be done. Then, if software specific modifications are needed, they should be done in one place, instead of introducing modifications to many different files throughout the project.

We should agree here, how we ask people to provide topology, and how we will use the topology. Now, NMRlipids uses TPR for GROMACS and doesn't use topology files from other engines, which is quite strange because, I see that MDanalysis actually does allow using various formats:
https://docs.mdanalysis.org/1.1.1/documentation_pages/topology/init.html

... including for example PSF. We also allow PSF in namd_dict (see databank_defs.py )

    "TOP": {
        "REQUIRED": False,
        "TYPE": "file",
        "EXTENSION": ("psf"),
    },

But then we... just don't use it and use PDB instead!

@comcon1 comcon1 changed the title Software-specific branching in several places. At the moment the organization makes adding new software or file formats for an old software very tedious. We should think how to resolve it. In general, the good thing is to make application general - software independent via drivers, which are software specific. So, a driver - middle-layer API, should take care of all software-specific manipulations producing a standardized output, from which the following steps should be done. Then, if software specific modifications are needed, they should be done in one place, instead of introducing modifications to many different files throughout the project Software-specific branching in several places should be avoided. Branching must be enveloped somehow. Dec 3, 2024
comcon1 added a commit to comcon1/Databank that referenced this issue Dec 16, 2024
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