Input sample that is not getting any response from the server

[Sachin Hegde]

Hello!

I am hereby attaching a sample graph input which is not getting any response from the server.

Are there any limitations for the load(in terms of number of joins between the tables) that can be handled by the server?

The input has 165 nodes(165 tables) and 524 edges(524 unique sample joins between the tables) and there is no cyclic relationship between the tables.

I would love to know the reasons why this is not working and hopefully some valuable suggestions to make it work.

Link to sample graph input file

[Dagobert Smart]

Hello,

I have no idea which application (or server) you are using.
OGDF itself is just a C++ library for graph drawing and graph algorithms. We do not run any public server for graph computations or database queries.
If you are using an application X which itself uses OGDF, I’d suggest asking for help in a forum for application X.

If you are just trying to read in the graph using the OGDF, you can do that with the following code (which works for me):

Graph G;
GraphAttributes GA(G);
GraphIO::read(GA, G, "graph_input.txt", GraphIO::readGML);

If you are using crossings.uos.de, then yes, it has a size limit of, I think, ~100 nodes and 200 edges. Crossing numbers for larger graphs cannot be computed because of the inherent hardness of the problem. There is not much we can do about that…

Best regards,
Dagobert

​

[Sachin Hegde]

Hello,

Thanks for that response. I have resolved that issue.

I have a code written 8 years ago using the old version which was available at that time, to get the svg and gml output.

For the above sample graph input, I am getting the svg output where the coordinates of the rectangle for each table are mentioned in the same order as the input.

We can verify it using the height and width combination of the rectangles and the same in the input.

Now I have written the same code for the latest version of OGDF.

I had to change some function names and parameters as they have been changed over many releases in the last 8 years.

But, when I this code, the coordinates of the rectangle for each table are jumbled up in different order in the svg output for the same input (they don't follow the order of the input).

Because of this, I can't determine which rectangle corresponds to which table.

Is the svg output supposed to be like that in the latest version or could I be making some mistake?

[Dagobert Smart]

Hello,

I don’t know what your code really does, so I assume it just reads a GML file and outputs the SVG.
In this case, the code looks as follows:

Graph G; GraphAttributes GA(G); if (GraphIO::read(GA, G, "graph_input.gml", GraphIO::readGML)){ GraphIO::drawSVG(GA, "test-graphml.svg"); }

For me, the rectangles are in the same order as for the input.
Maybe you have enabled GraphAttributes::threeD (which is also automatically enabled when you use GraphAttributes::all). In this case, the nodes are ordered by their z-value in order to display rectangles with a higher z-value on top. To disable this, either only enable the attributes you really need or explicitly disable threeD as follows:

GraphAttributes GA(G, GraphAttributes::all ^ GraphAttributes::threeD);

If your code changes the order of the nodes in some other way, it is probably a better idea to identify the rectangles using ids.
Then, you’d have to include the id in some svg attribute, e.g. the label:

Graph G; GraphAttributes GA(G, GraphAttributes::all ^ GraphAttributes::threeD); if (GraphIO::read(GA, G, "graph_input.gml", GraphIO::readGML)){ for (node v : G.nodes) { GA.label(v) = std::to_string(GA.idNode(v)); } GraphIO::drawSVG(GA, "test-graphml.svg"); }

Best regards,
Dagobert

​

[Sachin Hegde]

Hello,
That was so helpful. I was using GraphAttributes::all and could disable the threeD attribute as you suggested.

But, I have one more problem. the SVG output contains the coordinates of the polygon points for drawing the arrow at the end of each edge. Due to this, some edges have their paths specified only till the base of the arrow and the arrow connects the end of the edge to the destination table. But in my case, I need the edge paths specified right till the destination table and I don't need the arrows as I will have the source and destination list readily available for each edge even before generating the GML input and using that, I can draw a small arrow at the very end of the edge on my own.

Even if the output had the edge paths specified till the tip of the arrow, I could have just ignored the polygon points of the arrows even if they were present in the output. But, for some edges, since the path is specified only till the base of the arrow, it makes the edge disconnected from the destination table if I ignore the arrow.

So, please help me in avoiding the arrows and getting the edge path points coordinates specified till the very end(till the destination table and not to the base of the arrow).

[Dagobert Smart]

Hello,

I’m glad that I could be of help.
If you just want to disable the drawing of arrow tips, use this:

for (edge e : G.edges) { GA.arrowType(e) = EdgeArrow::None; }

This requires GA to have GraphAttributes::edgeArrow enabled (which is automatically enabled for GraphAttributes::all).

Best regards,
Dagobert

​

[Sachin Hegde]

Hello,

Thank you very much. I just took the x-y coordinates of the tip of the arrow from the polygon points and added it at the end of the edge path points and then ignored the polygon points. It is working fine so far.

I could compile and link the source files successfully using the below commands I found in your build guide :

c++ -Ibuild_path/include -Isource_path/include -o main.o -c main.cpp

c++ -o output_binary -Lbuild_path main.o -lOGDF -lCOIN

Everything is perfectly fine up to this point.

But, in my case, I want the shared object file(.so) or dynamic library file(.dylib) and I am trying to get it using the below command :

c++  -shared -o main.so main.o

and also

c++  -dynamiclib -o main.dylib main.o

But, both are giving the error as,

Undefined symbols for architecture arm64:
  "ogdf::OrthoLayout::OrthoLayout()", referenced from:
      main in main-1941f8.o
  "ogdf::BoyerMyrvold::planarEmbed(ogdf::Graph&, ogdf::SList<ogdf::KuratowskiWrapper>&, int, bool, bool, bool, bool)", referenced from:
      ogdf::BoyerMyrvold::planarEmbed(ogdf::Graph&, ogdf::SList<ogdf::KuratowskiWrapper>&, ogdf::BoyerMyrvoldPlanar::EmbeddingGrade, bool, bool, bool, bool) in main-1941f8.o
  "ogdf::Initialization::Initialization()", referenced from:
      ___cxx_global_var_init in main-1941f8.o
  "ogdf::Initialization::~Initialization()", referenced from:
      ___cxx_global_var_init in main-1941f8.o
  "ogdf::get_stacktrace(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)", referenced from:
      ogdf::EmbedderMaxFaceBiconnectedGraphs<int>::embed(ogdf::Graph&, ogdf::AdjElement*&, ogdf::NodeArray<int> const&, ogdf::EdgeArray<int> const&, ogdf::NodeElement* const&) in main-1941f8.o
      ogdf::StaticSPQRTree::StaticSPQRTree(ogdf::Graph const&) in main-1941f8.o
      ogdf::internal::GraphIteratorBase<ogdf::NodeElement*, false>::operator++() in main-1941f8.o
      ogdf::internal::GraphIteratorBase<ogdf::AdjElement*, false>::operator++() in main-1941f8.o
      ogdf::EmbedderMaxFaceBiconnectedGraphs<int>::expandEdge(ogdf::StaticSPQRTree const&, ogdf::NodeArray<bool>&, ogdf::NodeElement* const&, ogdf::NodeElement* const&, ogdf::NodeArray<int> const&, ogdf::NodeArray<ogdf::EdgeArray<int> > const&, ogdf::NodeArray<ogdf::List<ogdf::AdjElement*> >&, ogdf::NodeArray<ogdf::ListIteratorBase<ogdf::AdjElement*, false, false> >&, ogdf::NodeArray<ogdf::ListIteratorBase<ogdf::AdjElement*, false, false> >&, ogdf::AdjElement*&, ogdf::NodeElement* const&) in main-1941f8.o
      void ogdf::Graph::sort<ogdf::List<ogdf::AdjElement*> >(ogdf::NodeElement*, ogdf::List<ogdf::AdjElement*> const&) in main-1941f8.o
      ogdf::NodeArray<ogdf::List<ogdf::AdjElement*> >::operator[](ogdf::NodeElement*) in main-1941f8.o
      ...
  "ogdf::GraphAttributes::all", referenced from:
      main in main-1941f8.o
  "ogdf::GraphAttributes::threeD", referenced from:
      main in main-1941f8.o
  "ogdf::GraphAttributes::GraphAttributes(ogdf::Graph const&, long)", referenced from:
      main in main-1941f8.o

"typeinfo for ogdf::EmbedderMinDepthMaxFace", referenced from:
      typeinfo for ogdf::embedder::LayersBlockEmbedder<ogdf::EmbedderMinDepthMaxFace, ogdf::embedder::MDMFLengthAttribute> in main-1941f8.o
  "typeinfo for ogdf::ConstCombinatorialEmbedding", referenced from:
      typeinfo for ogdf::CombinatorialEmbedding in main-1941f8.o
  "vtable for ogdf::BoyerMyrvold", referenced from:
      ogdf::BoyerMyrvold::BoyerMyrvold() in main-1941f8.o
      ogdf::BoyerMyrvold::~BoyerMyrvold() in main-1941f8.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "vtable for ogdf::StaticSPQRTree", referenced from:
      ogdf::StaticSPQRTree::StaticSPQRTree(ogdf::Graph const&) in main-1941f8.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "vtable for ogdf::GraphAttributes", referenced from:

NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "vtable for ogdf::EmbedderMinDepthMaxFaceLayers", referenced from:
      ogdf::EmbedderMinDepthMaxFaceLayers::EmbedderMinDepthMaxFaceLayers() in main-1941f8.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I have mentioned some of the errors, there are some more errors of exactly the same pattern.

Can you please help me fix this issue in order to obtain the .so or .dylib file? Or, is there any other way to obtain the .so or .dylib file?

Thank you..