Remove deprecated formats, update reader and writer backends

[chrisjonesBSU]

PR Summary:

This PR gets things started to remove the deprecated items talked about in #1187

Also, this will update the reader/writer backends to use GMSO where ever possible.

PR Checklist

---

• Includes appropriate unit test(s)
• Appropriate docstring(s) are added/updated
• Code is (approximately) PEP8 compliant
• Issue(s) raised/addressed?

[chrisjonesBSU]

The failing tests are in test_xyz.py. The behavior we expect in the test is not what we get when using the gmso backend workflow. If we load a single molecule with infer_hierarchy = True do we expect the particles of the created compound to be children (the way the test is currently written), or do we expect a flat molecule (what we get from gmso)?

Also, if I change infer_heirarchy=False when using conversion.py the behavior is different from using GMSO directly and passing infer_hierarchy=False to from_mbuild.

Here is a gist showing what I'm trying to say here.

[CalCraven]

To organize my thoughts, the four use cases are:

1. Use mBuild to load xyz, infer_hierarchy=True
2. Use mBuild to load xyz, infer_hierarchy=False
3. Use GMSO to load xyz, infer_hierarchy=True
4. Use GMSO to load xyz, infer_hierarchy=False

As @chrisjonesBSU has in his gist, 1-3 gives a layered compound with 1 child, which then itself has 8 children particles. Method 4 gives a flat compound with 8 children.

We should agree on preferred behavior. I actually think the current output from Method 4 is what I would expect for all compounds made from xyz files. Do you agree or disagree @chrisjonesBSU?

My reasoning is since there is no hierarchy present in an xyz file, I would expect a consistent flat compound. Infer_hierarchy therefore should not make a difference either way, as what happens in the current mBuild methods.

In order to obtain this behavior, I think we could either tweak the to_mbuild function so that any topologies without molecule or residue information give a single compound with multiple particles. To me, that seems like the preferred way to convert to a compound without extra hierarchy info. However, we need to test that, as it could screw any behavior from other readers if we modify the to_mbuild method, which every other conversion pathway also takes.

An optional workaround is to just set the molecule/residue information when reading in xyz files such that the to_mbuild can be kept the same, but gives us the preferred outcome. Since that info is not really part of the xyz file, I think manually setting it in the xyz reader in a generalized manner is a way we get consistent results. It would need to be set such that we get the flat compound when infer_hiearchy=True, so gotta dig into that bit of the to_mbuild function still.

[chrisjonesBSU]

Still need to remove lampsdata.py and lamps unit tests.

[chrisjonesBSU]

There seems to be something funny going on with pytest and how it is caching things. test_resnames_parmed_cg is failing; however, if you just run that test only without running everything else in test_compound.py it passes.

pytest test_compound.py -k test_resnames_parmed_cg

Another way to test this is to disable cacheing

pytest test_compound.py -p no:cacheprovider

Then all 182 tests in test_compound.py pass.

[codecov]

Codecov Report

Attention: Patch coverage is 70.58824% with 10 lines in your changes missing coverage. Please review.

Project coverage is 85.93%. Comparing base (38077cd) to head (bbffe82).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
mbuild/conversion.py	67.85%	9 Missing ⚠️
mbuild/compound.py	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1191      +/-   ##
==========================================
- Coverage   87.35%   85.93%   -1.43%     
==========================================
  Files          62       53       -9     
  Lines        6588     4898    -1690     
==========================================
- Hits         5755     4209    -1546     
+ Misses        833      689     -144     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[chrisjonesBSU]

@CalCraven we previously discussed about still having support for saving .lammps and .lammpsdata files directly from mBuild, but the wrtiers we have in GMSO for this only work with typed topologies. So, for now I removed these file types from tests.

[chrisjonesBSU]

The windows 3.12 test should pass once conda-forge/gmso-feedstock#27 is merged and available.

The windows 3.12 run is sort of unique, it has to use the latest version of GMSO because of a PR fixed related to importing hoomd, but the latest GMSO doesn't support python 3.12. Some of the older versions must not have pinned a maximum python version, which is why the other 3.12 tests are passing.

[chrisjonesBSU]

@CalCraven This should be ready to go.

[CalCraven]

Few more minor comments actually, mostly about some doc strings.

[CalCraven]

Would it be better to pass the following conversion mapping in the documentation. Then we just link to

mbuild/mbuild/conversion.py

Line 936 in e42cd01

def save(

for more details?

`{GMSO: {".gro", ".gsd". ".data", ".xyz", ".mcf", ".top"},
ParmEd: {".mol2", ".pdb", ".prmtop", ".cif", ".crd"},
PyBel:{".sdf"}}`

[chrisjonesBSU]

Good idea. This should be done, along with the other suggestions.