dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?

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