| Thread Previous • Date Previous • Date Next • Thread Next |
Anders Logg wrote:
On Tue, Apr 24, 2007 at 01:24:01PM +0200, Garth N. Wells wrote:Garth N. Wells wrote: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.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? GarthI 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 oldcode,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.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.With the displacement fixed at one end only and a unit body force in all directions,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?( ||u^old||_2 - ||u^new||_2 ) / ||u^old||_2 = 0.001and 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".GarthGreat! 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. /AndersGarth/AndersGarth/AndersGarthThis 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
| Thread Previous • Date Previous • Date Next • Thread Next |
