# Best format for exporting igraph network for use in other software (e.g. ORA for dynamic networks)?

**URL:** <https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643>\
**Category:** Usage\
**Tags:** R\
**Created:** [25 February 2021 08:35 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643 "2021-02-25T08:35:35Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![jwhyte](https://avatars.discourse-cdn.com/v4/letter/j/ce73a5/32.png) [@jwhyte](https://igraph.discourse.group/u/jwhyte)\
**Post date:** [25 February 2021 08:35 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/1 "2021-02-25T08:35:35Z")

</div>

I’m just starting to look into dynamic networks, especially looking at changes in edge weights over time. I plan to export individual igraph networks to ORA (_but I do not think this end point is key to my question_) and assemble them into the dynamic network.

(For details on ORA, see [Projects - \*ORA-LITE | CASOS](http://www.casos.cs.cmu.edu/projects/ora/) which begins with:  
"ORA-LITE is a dynamic meta-network assessment and analysis tool developed by CASOS at Carnegie Mellon. It contains hundreds of social network, dynamic network metrics, trail metrics, procedures for grouping nodes, identifying local patterns, comparing and contrasting networks, groups, and individuals from a dynamic meta-network perspective. \*ORA-LITE has been used to examine how networks change through space and time … ")

I want to use `write_graph()` to export an igraph network to a file format that retains

1. node name/id (very useful),
2. edge weight (quite useful),
3. node size (not essential, but desirable as this may change over time).

After some experimentation I’ve found that exporting to Pajek format (.paj) gives me 1. and 2. when I open the file in ORA. (I can’t see how to get 3, but I’ve never used Pajek and might be ignorant in my experiments.) Writing to .graphml gives me 2. and 3. when I open the file in ORA. At the moment I’m leaning towards the Pajek approach.

I saw this post on .graphml/node ids from seven years ago:

> <https://stackoverflow.com/questions/18502174/writing-graphml-files-changing-the-node-names-to-an-attribute>

suggesting that some processing of node ids in the .graphml was the way to proceed.

I will be looking at some pretty large dynamic networks soon, a few thousand nodes over each of maybe 20 years. I am looking for suggestions on how to proceed efficiently.

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [25 February 2021 17:40 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/2 "2021-02-25T17:40:18Z")

</div>

What is ORA? Can you give a link or explanation?

---

<div class="post-metadata">

**Author:** ![jwhyte](https://avatars.discourse-cdn.com/v4/letter/j/ce73a5/32.png) [@jwhyte](https://igraph.discourse.group/u/jwhyte)\
**Post date:** [25 February 2021 19:04 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/3 "2021-02-25T19:04:04Z")

</div>

I’ve edited the original question, but I do not think that the end point of ORA is key to my question.

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [25 February 2021 19:43 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/4 "2021-02-25T19:43:08Z")

</div>

> [@jwhyte](#):
>
> I do not think that the end point of ORA is key to my question.

Well, the title of your question is “Best format for exporting igraph network for use in ORA?” …

Of the formats igraph supports, GraphML, GML, DOT and Pajek all support arbitrary edge and vertex attributes, so they can store what you are asking for and more. GraphML is probably the most widely supported.

I am not familiar with ORA, so I do not know what it can read and how it can interpret data from these formats.

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [25 February 2021 19:45 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/5 "2021-02-25T19:45:43Z")

</div>

> [@jwhyte](#):
>
> After some experimentation I’ve found that exporting to Pajek format (.paj) gives me 1. and 2. when I open the file in ORA.

How to map a certain attribute to vertex size in ORA would be a question that is unrelated to igraph, and is specific to ORA.

---

<div class="post-metadata">

**Author:** ![jwhyte](https://avatars.discourse-cdn.com/v4/letter/j/ce73a5/32.png) [@jwhyte](https://igraph.discourse.group/u/jwhyte)\
**Post date:** [25 February 2021 19:49 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/6 "2021-02-25T19:49:48Z")

</div>

Well, maybe, or perhaps I have an issue with setting the igraph vertex size in a form that’s incorporated into the .paj file when I use `write_graph()`? Any tips on this?

---

<div class="post-metadata">

**Author:** ![jwhyte](https://avatars.discourse-cdn.com/v4/letter/j/ce73a5/32.png) [@jwhyte](https://igraph.discourse.group/u/jwhyte)\
**Post date:** [25 February 2021 19:51 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/7 "2021-02-25T19:51:41Z")

</div>

A fair point. As my understanding has matured a little, I’ve edited the question.

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [25 February 2021 19:54 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/8 "2021-02-25T19:54:07Z")

</div>

Let me try to rephrase. Graph formats which are designed to be flexible, and not tied to a specific piece of software, can typically store arbitrarily named vertex and edge attributes. In general, there is no way to store “vertex size”, with a guarantee that any software that opens the file will immediately use that to adjust size. However, a software that can plot graphs may be able to map any vertex attribute of your choice to size when plotting. (igraph can do this.)

I do not know ORA at all, but based on my experience with other software, I would try these in order:

- Figure out how to map an arbitrary vertex attribute to size in ORA.
- If that is not possible, I would look at what ORA calls the attribute that it interprets as “size” (by e.g. exporting a graph with different vertex sizes to GraphML from ORA and looking into the file), and use the same attribute name in igraph.
- DOT is specific to Graphviz and Pajek is specific to, well, Pajek. Both of these software can visualize graphs. Therefore, maybe these do have a standard name for the attribute they interpret as size. If they do, _maybe_ ORA also interprets it as size. I might try this as a last resort.

I hope this helps.

---

<div class="post-metadata">

**Author:** ![jwhyte](https://avatars.discourse-cdn.com/v4/letter/j/ce73a5/32.png) [@jwhyte](https://igraph.discourse.group/u/jwhyte)\
**Post date:** [25 February 2021 22:42 UTC](https://igraph.discourse.group/t/best-format-for-exporting-igraph-network-for-use-in-other-software-e-g-ora-for-dynamic-networks/643/9 "2021-02-25T22:42:04Z")

</div>

I think I have definitely introduced a “red herring” in ORA, sorry. I think the main issue is that exporting some igraph to Pajek format is easiest to work with for my needs, but I can’t see how to include vertex information in a .paj file. (Alternatively, exporting to .graphml associates igraph’s V(g)$size with a v\_size field for each vertex.)  
Here’s a short R example that shows my failure:

```
library(igraph)
g <- graph.star(10)
V(g)$name <- letters[1:10]
# Pajek doesn't recognise these names, so use a new attribute to set vertex ids - these show up in the exported Pajek file
V(g)$id <- as.character(V(g)$name)
# Set some arbitrary edge weights for illustration - these also show up in the exported file.
E(g)$weight <- seq(1:length(E(g)))*2.5
# This attempt to change the vertex sizes doesn't have any effect in the output file
V(g)$size <- as.numeric(seq(1:length(V(g)))*5)
# Pajek documentation suggests vertex sizes are set with "s_size", but this new attribute also does not appear in the exported file:
V(g)$s_size <- V(g)$size
Write graph g to a Pajek file
igraph::write_graph(g, file =test , format = "pajek")

```

produces a file with contents that omit the new attributes  
\*Vertices 10  
1 “a”  
2 “b”  
3 “c”  
4 “d”  
5 “e”  
6 “f”  
7 “g”  
8 “h”  
9 “i”  
10 “j”  
\*Arcs  
2 1 2.5  
3 1 5  
4 1 7.5  
5 1 10  
6 1 12.5  
7 1 15  
8 1 17.5  
9 1 20  
10 1 22.5

Obviously some of my attempts to add attributes were successful (edge weight, vertex id). I think I need an igraph → Pajek dictionary. Does anyone have suggestions?

( **EDIT:** Pajek handles vertex attributes through a separate .vec file. However, we can re-purpose the x-coordinate or y-coordinate columns of a .paj file to hold vertex size. I can successfully use one of these attributes in resizing my vertices in ORA (setting V(g)$x or V(g)$y to my intended sizes). A bit clunky, but might have to do until someone comes up with something more clever.)