DataArray names f_* break ParaView animations

[Nico Schlömer]

When writing out data to (VTK) files, the point data used to have the name u as in

<DataArray  type="Float64"  Name="u"  format="ascii">

Now, the naming scheme seems to be f_%d, where %d is some integer, e.g.,

<DataArray  type="Float64"  Name="f_17"  format="ascii">

For a sequence of files, this makes it impossible to show the data continuously in ParaView since ParaView understands differently named data arrays as different entities.

[Martin Sandve Alnæs]

Provide a name like this: f = Function(V, name="p")

[Prof Garth Wells]

When does output get the f_%d label? I just tested for the Cahn-Hilliard demo and the label is just u.

[Martin Sandve Alnæs]

From python, I added the name= argument and set the default to a unique name. Maybe the default should still be "u".

[Martin Sandve Alnæs]

(This was one of the changes that got accidentally merged into master, I only added it to next and planned to get feedback before merging into master)

[Prof Garth Wells]

Is this in the 'master' branch? I just got u in my output

Unique names are nice. Maybe it just needs something after the integer to not mess with the VTK and ParaView?

It would also be best to have consistent behaviour across the C++ and Python interfaces.

[Martin Sandve Alnæs]

Yes: In [4]: f = Function(V)

In [5]: f.name() Out[5]: 'f_0'

In [6]: File("f.pvd") << f

... '<PointData Scalars="f_0"> \n',

[Johan Hake]

The digit comes from the UFL count of the Python version of the Function. We would need to have some internal counter for this within DOLFIN to get it into C++.

[Martin Sandve Alnæs]

We could use the Variable id.

[Nico Schlömer]

In the application, technically I'm creating a new function in each step that's then written out, i.e.,

ufile = File('results/temp.pvd')
while t < T:
    u = computeU()
    ufile << u

It'd be no problem to do something like

ufile = File('results/temp.pvd')
u_1 = Function(V)
while t < T:
    u = computeU()
    u_1.assign(u)
    ufile << u_1

but anyways the previous approach used to work as well.

[Martin Sandve Alnæs]

I see. It should also work if you set the name of the Function created inside and returned from computeU to be the same.

To summarize: - There is a workaround, you can set the name explicitly to what you want in the Function constructor. - It may still be that we have to revert the default name to "u" for compatibility. - Paraview may be doing funny things with names ending with _%d, so we may need a different default formatting even if we keep names unique.

My question to other developers/users: - Will the name workaround always be sufficient? - Do we need to keep compatibility with default name "u"?

[Nico Schlömer]

For ParaView it doesn't matter if the name is myfancyname or f_13124 -- for animations, it's just important to have the same name for the data throughout all files.

[Prof Garth Wells]

I think the new code is fine. We never guaranteed that a Function would have a particular name. A user can specify the name if necessary.

[Nico Schlömer]

I share Garth's view here. Closing.

[Nico Schlömer]

Closed.