dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?

> >> 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".

/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