Cannot make sample molecules from all atom types

[rwest]

Bug Description

Used for testing the database, there is a function that makes a sample molecule from a given functional group definition: rmgpy.molecule.Group.make_sample_molecule().

If you give it the simplest possible group definition for an atomtype, it should be able to make a molecule that matches.
Eg. give it the group 1 C ux and it'll return methane (the simplest way to get C). Give it 1 Cd ux and it'll give ethene (the simplest way to get C with a double bond). etc.
But there are a few atom types for which it does not work.

How To Reproduce

Introduced in commit 15ca27e in pull request #1661
is a unit test that checks them all. Basically,

        for name, atom_type in rmgpy.molecule.atomtype.ATOMTYPES.items():
             adjlist = f"1 {name} ux"
             group = rmgpy.molecule.Group().from_adjacency_list(adjlist)
             try:
                 result = group.make_sample_molecule()
                 if not result.is_subgraph_isomorphic(group):
                     failed.append(name)

And some fail.
The atom types Xo, Cq, Sib, Sibf, Siq do not make sample molecules that match their chosen atomtypes.
The atom types O4b and S4b crash when you try to make sample molecules.

Installation Information

Describe your installation method and system information.

• true on MacOS and the ubuntu used to run the automated tests.
• RMG version information:
  • RMG-Py: 15ca27e

Additional Context

I think the method is only used for testing the database, and is not causing any crashes. So possibly low priority. Until, however, it becomes a problem. For example, it was an atom type error (that this test would have caught) that caused a hard-to-debug segfault when updating the database a few years ago #1656
So if anyone tries adding Cq, Sib, Sibf, or Siq atoms (or O4b or S4b) to the database, they may wish this worked better.

[github-actions]

This issue is being automatically marked as stale because it has not received any interaction in the last 90 days. Please leave a comment if this is still a relevant issue, otherwise it will automatically be closed in 30 days.

[JacksonBurns]

@rwest since this is a testing enhancement that only seems to come up on the frequency of years, I'll go ahead and close this now but put it in the long-term project table as a nice to have.