https://en.wikipedia.org/wiki/Project_network#:~:text=A%20project%20network%20diagram%20is,on%20the%20relationship%20among%20them.

Create such things. It would be useful in many cases for structural analysis of graph.

Create more simple samples and add README.md to each of them in order to explain what this library can do.

I tired of constatntly type checking all of this. Redesign the whole library.

Holding all code of library, benchmark and samples in one repo is convenient for development, but it create a lot of noise in commits history (which btw is really a mess. Are you just too lazy to create good commits?).

It just takes a lot of time to do this operation in NodesFactory. Try to refactor it and optimize

Remove example from main README.md and create examples in samples folder.

Any graph can be represented as following structure

[node1,node2,weight1],
[node3,node5,weight2],
...

Add converters for this things

https://www.youtube.com/watch?v=wUgWX0nc4NY

https://en.wikipedia.org/wiki/Closure_problem

It would be pleasant that your algorithms could work on any representation of graph.

You have a sample that find the shortest path between two nodes, but have no example about finding the shortest path that visit all nodes. Do it pls.

This method will create graph tree structure

Also maybe rename all variables in code from parent-child to something like parent-edge.

Let it be Children inside of INode, but the IChild and other components must be renamed to Edge.

Add wide rage of IVisitor.Select and IVisitor.EndVisit tests.
Maybe add separate tests for IPropagators.

Create more tests for separate components more than integrated tests, where all of them works together.

For example create custom empty Propagator and feed it to IGraph in order to test IGraph implementation more than IPropagator one.

Do the same for IPropagators.

Currently your Graph accepts only nodes that going in the same order as their Id. In the same time each node must contain Children-edges that are from the same set of nodes. This is bad. It means users can add to Graph whatever they want as nodes, which can be invalid set of nodes. In the same time you have NodesFactory, that capable of creating right set of nodes and edges. Maybe you somehow link them?

Accept in Graph constructor NodesFactory instead of nodes itself. Make checks that this factory nodes count > 0 and make copy of it's nodes to current instance of Graph.

But in the NodesFactory you have a bunch of methods to set and manipulate nodes whatever the way you want. This can also lead to errors. For example you can set WorkingGroup to any set of nodes, not strictly the same set from currently working NodesFactory instance. Honestly, I have no Idea how to fix it, but maybe add a bit more warnings in the description of methods of NodesFactory?

This part is really slow

        IEnumerable<IEdge> INode.Edges => this.Edges.Select(n=>n as IEdge);

It will do Select for each edge any time you will try to access Edges property. Because if this current version of library is 3x slower than previous one. Fix it

Kraskal's algorithm
Just choose the shortest edges in whole graph where at least one end is free, then combine them in single tree

You are really bad at English, which is fine by itself, but my eyes bleed when I am trying to read your documentation. Pls do something about it.

I am taking about how Visitor works. It is not obvious from what you written in methods description. It is not obvious how selector affect next generation of nodes and what role Visit method has.

Also it is not obvious what IPropagator is and what it is doing.

You did little-to-none in order to explain what Graph.Step doing, and why it is even named step, if it using IPropagator? Maybe rename ot to Propagate?

Also add better description to README.md

This one will be similar to finding the shortest path, but still useful as example.

Use ores and dirac's theorem.

ore theorem
dirac theorem

Your current impl of GraphStructure require a lot of lambda-configurations for it to work properly, meanwhile a lot of them may be not used in some cases of creating / altering nodes. This mean you break SRP in your GraphStructure instance. Fix it by dividing this big classes GraphStructure to separate more contained classes.

spanning tree
cutting set
tree binary code
center, radius, graph diameter
additional graph
Kraskal's algorithm

1:

Refactor FindTheShortestPath sample. It just looks ugly. Update readme and docs in general. Remove example from readme and move it to samples. Add separate readme to each sample.

2:

Redesign NodeGraphFactory
Rename it to be just NodeFactory.
Create chain-like mechanism to creating nodes

NodeFactory
.Create() //create new list of nodes
.Use(nodes) //or use existing nodes
.Count(2000) //create 2000 nodes
.Connect(20) //connect each to exact 20
.ConnectRange(1,10) //connect randomly to some range of nodes
.ConnectToClosest((node1,node2)=>...integer...);
.MakeDirected()
.MakeUndirected();
//Etc...

Where ConnectToClosest is a type of connection you used in a find path samples. It just works so cool you MUST add it to default connection methonds.

Also pass to this methods all Funcs you need in order to create different types of nodes and children.

Use pipeline pattern to implement this.

3:

You current graph implementation of ParallelGraph and just Graph are bad. You using some other thing like IPropagator in order to 'hide' implementation that differs from graph to graph. Move this implementation out of the class itself. Do something with it so it will follow bridge design pattern, so singe Graph class will be able to became single threaded and parallel depend on this type.
Hinit - let users change IPropagator type to graph on their own, but let it by default be parallel, so it will make things a bit easier to maintain.

Also currently your IPropagators are doing almost the same thing in a very similar way. This breaks DRY principal. Do something about it.

4:

Add more tests for graph and other components of graph. Currently your tests are poor and do not cover all code behaviour properly.

5:

Implement second example - VisitAllNodes

6:

Currently for the sake of visualisation you using GraphDrawer which works fine but it is too much bound to imageSharp library. I mean you could in theory create some Avalonia.UI application that will use this class to draw graph on canvas dynamically.(which I hope you'll do, because WE NEED visualisation for GraphSharp). It's a shame that you so much lacks frontend skills.

Create graph visualisation in separate repository https://github.com/Kemsekov/GraphSharpGUI

7. Update documentation to follow changes in api.

It's been a while so it makes sense to port them here.

Problem

INode.Edges must be read-only. You cannot add or delete Edges from casted to down-level INode.
Currently your INode.Edges is IList which allows to add and remove nodes.

Solution

Create your own ImmutableCollection for list that also allows casting from inherited to base classes.

Your Propagator and ParallelPropagator is exactly doing BFS(«go wide, bird’s eye-view») from a graph theory. Rename it accordingly in order to avoid misunderstanding.

https://en.wikipedia.org/wiki/Maximum_flow_problem
https://en.wikipedia.org/wiki/Minimum-cost_flow_problem
https://en.wikipedia.org/wiki/Network_simplex_algorithm
https://en.wikipedia.org/wiki/Multi-commodity_flow_problem

https://en.wikipedia.org/wiki/Minimum_cut
https://en.wikipedia.org/wiki/Minimum_k-cut

move to the closest node each iteration. Do not visit the same node twice except for the first one(it will lock the cycle).
Every time you meet dead end(no avalliable path or someth) just go back to one