I have one query about modifications with graphs.
There is a subgraph that I identify using pattern matching and remove it.
The intention is to replace that part with another graph. Using the
graph_union function
the graphs are combined structurally, however, all the properties of the
graph being
inserted are lost. Is there any way for insertion of subgraphs with the
properties preserved?

Yes, take a look the documentation for the graph_union() function, in
particular the 'props' parameter. It lets you provide a list of property
maps which are merged in the combined graph.

Thanks. That did help.
However, I should have been specific in mentioning vertex properties.
The graph union function merges graph properties. My subgraph nodes have
a few additional vertex properties as compared to the main one and these
do not get merged automatically. I wrote a few lines of code to accomplish
that,
but, just wanted to know if the props parameter in graph union function can
handle that too.

You can merge as many property maps as you want, just by passing a list
to graph_union() with all the properties you want merged. If a given
property map is only defined for one graph, but not the other, then you
must create an empty property map for the other graph, in order for it
to be merged. This is not handled automatically by graph_union(), but
maybe it should...

It did not do that. I anyway have a workaround for that.
There's another issue I am encountering. Before doing a union of
two graphs (g1, g2), I filter out 5 vertices in g1 which actually has 20
nodes,
leaving it with 15 vertices. The num_vertices() function returns the value
15 but the
last node still has an index of 19. So after union, in the vertex list the
graph g2 gets
appended to the end of g1, which I assumed to be starting at index 15, but
its at 20.

I understand that the filter is reversible, but is there any way
to re-arrange indices after a filtering operation so that there is a
consistency with the
vertex index and the number of vertices actually being considered now?

It did not do that. I anyway have a workaround for that.

Do what exactly? Handle the case where a property is defined for only
one graph? This is not yet implemented, I just mentioned it would be
perhaps a good idea.

There's another issue I am encountering. Before doing a union of two
graphs (g1, g2), I filter out 5 vertices in g1 which actually has 20
nodes, leaving it with 15 vertices. The num_vertices() function
returns the value 15 but the last node still has an index of 19. So
after union, in the vertex list the graph g2 gets appended to the end
of g1, which I assumed to be starting at index 15, but its at 20.

I understand that the filter is reversible, but is there any way to
re-arrange indices after a filtering operation so that there is a
consistency with the vertex index and the number of vertices actually
being considered now?

There is no way to change this and still have a vertex/edge filtering
which is at the same time very cheap (O(1)) and reversible. Thus, in
general, you cannot rely on a continuous vertex index range, if you have
filtered graphs.

What you can do is purge the filtered vertices with purge_vertices(), or
create a new unfiltered graph copy, i.e.

u = Graph(g, prune=True) # g is a filtered graph, u is not

In this way, the indexes of u.vertices() will be coherent with
num_vertices(), the way you want.