Optimizing list order to reduce total graph link distance

Question

Summary

I'm looking for an algorithm that will accept an undirected graph, and return its vertices sorted in a single dimension, to reduce the total edge length. I think.

Example

I'm leaving out some context I'd be happy to give, but for simplicity, I started off with this example data in a UI I'm building:

The goal is to show correlation between the nodes, which in reality, represent topics from an NLP algorithm.

The trouble is, as you can see, it's a bit jumbled. It looks like a mess of wires, despite the underlying graph being fairly simple.

It's much more readable like this:

Obviously it could be rotated any which-way, but this is one possible optimal result.

Goals

Looking at this initially, I thought the goal was to reduce intersections. Not that I know how to do that either, but I quickly realized that a and e, in this simplified example, could be transposed without introducing an intersection, but while still jumbling it up.

In a move to define mathematically what "jumbling it up" meant, I've concluded I think I want to reduce the overall distance (in vertices, not pixels, if that makes sense) that all links have to travel. In this example, I could say that there's only one "skipped" vertex--c-b skips f--so that's much more optimal than the nine of its alphabetically-sorted equivalent.

Complications

I'm pretty far out of my expertise here, so I don't know what I'm doing in general. But with that said, I think it adds a bit of complexity since the chart-to-be is circular. Might not be a big deal, but the fact that, say, index 6 may fall adjacent to 0, or 5 is only two away from 1, could complicate some of it.

I don't know how common this is, but it seems unusual that the movement of vertices within my ordered set impacts others. For example, in the alphabetical example above, move h to be between d and e will reduce d-h to zero, but it will increase the edge length for c-e. c-f will remain the same distance, only because it can go on the route through a and b after being shifted. a-e would be improved. It happens this works out to a net improvement, but it often doesn't.

Of course, the same is particularly true of nodes with multiple links. Swapping b with a will help b-f and maintain the same distance for a-e (because of the circle, again), but it will increase b-c and b-d, and thus be a bad choice.

Analogies

When I first stumbled across this, it looked like a mess of wires to me. That got me thinking, there must be a good algorithm for, say, optimizing server placement in a datacenter. Some servers on the network would have to talk, and would be advantaged by being near each other. That would be a two-, perhaps three-, dimensional version of this, but the theory is very similar.

I also learned about Minimum routing cost spanning trees, which seem super similar, but a bit of reading (most of which I, admittedly, barely understood) suggests that, like most such problems I've found, their focus is more on selecting edges, so I'm not sure whether that helps me or not, since my edges are predefined.

Another part of me feels like this has some Traveling Salesperson vibes, but it's still...pretty different.

Not gonna lie, I'm pretty lost. I'm convinced this would be a fundamental problem within graph theory, but I haven't found the right search terms to find known solutions (or approximations, as the case may be).

Attempt

With that said, I did put something together; I'm just not proud of it. My current algorithm will crash a browser pretty easily. But it works okay, outside of some edge-cases I've deferred while I find a better solution.

1. Calculate the total edge distance for the graph
2. For each iteration (up to 1,000, unless converged earlier)
   1. For each vertex
      1. Calculate the mean index for its linked siblings
      2. Test the total edge distance if the node were moved to that mean index
      3. If it's the best improvement we've found, store it until we're ready
   2. Now that we have a "best improvement," move the node, then start again
   3. If we can't find any improvements, enter a special-case:
      1. Pretty much the same thing, except test moving the node step-by-step toward its mean. This helps compromise when nodes are particularly expensive to move.

There are a couple optimizations, but this was largely just a stream-of-consciousness to validate my goal, and the UI in general.

I'm pretty pleased with the output, including on much more complicated graphs, but it's still very much a brute-force approach.