← Back to team overview

dolfin team mailing list archive

Re: [HG dolfin] Fix VTK outout. Results look ok now.

 



Anders Logg wrote:
On Tue, Apr 24, 2007 at 01:24:01PM +0200, Garth N. Wells wrote:

Garth N. Wells wrote:
Anders Logg wrote:
On Tue, Apr 24, 2007 at 11:14:01AM +0200, Garth N. Wells wrote:
Anders Logg wrote:
On Mon, Apr 23, 2007 at 11:31:40PM +0200, Garth N. Wells wrote:

Anders Logg wrote:
On Mon, Apr 23, 2007 at 06:50:17PM +0200, Garth N. Wells wrote:
Quoting Anders Logg <logg@xxxxxxxxx>:

On Mon, Apr 23, 2007 at 07:04:16PM +0200, DOLFIN wrote:
One or more new changesets pushed to the primary DOLFIN repository.
A short summary of the last three changesets is included below.

changeset:   2900:cc8dbffbcc9cebe6761eceb5b91d324e0ec2caf0
tag:         tip
user:        "Garth N. Wells <g.n.wells@xxxxxxxxxx>"
date:        Mon Apr 23 19:04:03 2007 +0200
files:       src/kernel/io/VTKFile.cpp
description:
Fix VTK outout. Results look ok now.
Very nice. Maybe we should put back the same boundary condition as we
had before and compare the results (the solution vector number by
number) with the old demo. That would be a very good indicator that
we are on the right track.

Do we still need to do some work on applying Dirichlet boundary conditions to
particular components of a vector only, or is this already implemented?

Garth
I think this is not needed for the elasticity demo since we set the
values for all the vector components. The displacement is u = [0, 0, 0]
at one end and u = [ux, uy, uz] at the other end.

Looks like the boundary condition at one end is u = [-, uy, uz].
ok, I see that now. It's sort of a strange boundary condition. You
twist the gear around the x-axis but allow it to slide in the
x-direction.

I've applied the same boundary conditions for the new and the old
code,
Setting ux to 0 in both?

I set ux = 1 in the second.
Isn't u the displacement? So ux = value[0] should be set to 0, not 1?

I can set it to anything to get a non-trivial solution.

and the results are close, but not the same. One issue is that FFC is producing code with fewer significant digits than previously.
How close?

With the displacement fixed at one end only and a unit body force in all directions,

  ( ||u^old||_2 - ||u^new||_2 ) / ||u^old||_2 = 0.001

and with no body force, just applied displacements (RHS vectors are identical),

  ( ||u^old||_2 - ||u^new||_2 ) / ||u^old||_2 = 0.0003.

These numbers look small, but they hide that the results do jump around a bit.
I would expect us to get much closer.

Kristian and I reduced the number of significant digits to get
reproducible results when running the regression test in FFC. (The
last digits may otherwise differ between different machines, Python
versions, time of day, weather conditions etc.)

Can I easily increase the number just for testing?
Yes, just change the entry "floating point" in the format dictionary
in ufcformat.py. We had "%.15e" before and have change to "%.13g".

The number of significant digits doesn't appear to be the problem. I'm testing a smaller problem and it looks like the RHS vector is not being initialised correctly. I'm still looking into it.

It appears that the elasticity demo is ok. The reason for the discrepancy in results lies in the application of boundary conditions. Previously, Dirichlet boundary conditions were imposed vertex-wise, whereas now they are imposed for all vertices which belong to a facet which has been tagged for a boundary condition. When applying identical boundary conditions, the results are near-identical.

Garth

Great!

Is it ok to put back the old boundary conditions (the rotation) now?


Sure, but this isn't possible yet?

Another thing is ConstantFunction has changed. Previously,

  Function f = 1.0

mean that all components of a vector function has value 1. Now

  Function f(mesh, 1.0)

implies f = [1, 0 ,0].

Garth



I'd like to check that it works with the latest viper.

/Anders


Garth

/Anders


Garth

/Anders


Garth

This problem does not show up until we get to the Stokes demo.

/Anders
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev



Follow ups

References