dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Apr 24, 2007 at 01:49:51PM +0200, Garth N. Wells wrote:
> 
> 
> 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?

Yes, it should be possible as long as we set ux = 0 at the right end
where the rotation is. (This should make more sense than having a
Neumann condition for ux there.)

> 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

Does it? In ConstantFunction::evaluate(), we have

  // Set all values to the constant value
  for (uint i = 0; i < size; i++)
    values[i] = value;

Is the problem only that the computation of the size is done after the
call to evaluate_dof (which calls evaluate) in
ConstantFunction::interpolate()?

/Anders


> 
> 
> 
> > 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
> > 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev