← Back to team overview

dolfin team mailing list archive

Re: zero normal velocities / corrupted vtk output

 

Anders Logg wrote:
On Mon, May 17, 2010 at 09:23:55AM +0100, Garth N. Wells wrote:

On 17/05/10 09:18, Anders Logg wrote:
On Mon, May 17, 2010 at 09:11:43AM +0100, Garth N. Wells wrote:

On 17/05/10 09:00, Anders Logg wrote:
On Mon, May 17, 2010 at 09:50:22AM +0200, Patrick Riesen wrote:
Anders Logg wrote:
On Fri, May 07, 2010 at 02:39:41PM +0200, Patrick Riesen wrote:
hello,

i want to zero the normal velocity on a boundary part of my
2D-domain, so i used something like

n = cell.n
a = ... + inner(w,dot(v,n)*n)*ds(2) + ...

in my form-file (w=testfunction, v=trialfunction).

i marked the boundary part using the "exterior facet domains"
meshfunction, which will be picked up in assemble(..):

MeshFunction<   uint>* _ext_facet_domains =
mesh.data().create_mesh_function("exterior facet domains", 1)

*_ext_facet_domains = 5;
boundary.mark(*_ext_facet_domains, 2)

can i do this? or what is wrong with the above way? because i don't
get zero velocities...

thank your for help,

patrick
What if you add a (big) parameter in front of that term? Does it have
any effect at all on the solution?

I would also suggest writing the term as

 dot(w, n)*dot(v, n)*ds(2)
thank you for the help anders,

so i noticed the following:
without parameter in front, i could see no effect at all. if i add a
parameter C in front and increase it stepwise until C is about 10^6
i can observe how the velocities cancel out on that boundary.

i guess this approach works, but there is something else:
looking at the (time-dependent) solution (*pvd file set or single
vtu files) in paraview, i ran into several

ERROR: In /home/kitware/Dashboard/MyTests/ParaView-3-8/ParaView-3.8/ParaView/VTK/IO/vtkXMLDataReader.cxx,
line 509
vtkXMLUnstructuredGridReader (0x1398ce0): Cannot read point data
array "U" from PointData in piece 0.  The data array in the element
may be too short.

I noticed that the reader crashes on some absurd numbers appearing
in PointData "U"  as

[...]
-3.949617e-105 9.769857e-104 0.000000e+00
[...]

If i set those to zero, there is no problem. but the appearance of
such  'almost-zero' numbers is clearly connected to using the
parameter C.

do you suggest me another way how to do this?

or do you think that the VTK output writing should check for numbers
<   DOLFIN_EPS to avoid such corrupted output, and the approach is ok?

best regards and thanks for the support,
patrick
It would be easy to add such a check (zero numbers below DOLFIN_EPS).
I'll let Garth comment first since he wrote most of the VTK output.

I haven't added this check for performance reasons, plus to me it's
a VTK bug.

We could add an option to Function so that

    Function::compute_vertex_values(...)

checks for small values.

Garth
Is that really an issue? A comparison against DOLFIN_EPS should take
very little time compared to writing a value to file.

Maybe not, but it's more code in DOLFIN to cover up for bugs in
other libraries. In this case, it seems to only affect users of
32-bit ParaView.

i was using a 64bit paraview binary on a 64bit machine...

I can add a function to File to strip small values - it can be used
by other output formats too.

Sounds good.

--
Anders


------------------------------------------------------------------------

_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dolfin
More help   : https://help.launchpad.net/ListHelp




References