dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Thursday 18 December 2008 06:22:40 Evan Lezar wrote:
> On Thu, Dec 18, 2008 at 7:00 AM, Johan Hake <hake@xxxxxxxxx> wrote:
> > On Wednesday 17 December 2008 22:21:06 Anders Logg wrote:
> > > On Wed, Dec 17, 2008 at 09:06:55PM +0100, Johan Hake wrote:
> > > > On Wednesday 17 December 2008 20:41:24 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:   5405:96d1443b6830dda228122b9dcd34d52f38906598
> > > > > tag:         tip
> > > > > user:        Anders Logg <logg@xxxxxxxxx>
> > > > > date:        Wed Dec 17 20:41:16 2008 +0100
> > > > > files:       TODO demo/pde/waveguide/cpp/Forms.form
> > > > > demo/pde/waveguide/cpp/main.cpp demo/pde/waveguide/python/demo.py
> > > > > description:
> > > > > Get waveguide demo running. Results in Python and C++ differ.
> >
> > Strange.
> >
> > > > Try a recompile of the cpp demo. It worked for me :P
> > > >
> > > > Johan
> > >
> > > Not for me.
> > >
> > > With C++, I get
> > >
> > >   Cutoff frequency = 7.02634
> > >
> > > and with Python, I get
> > >
> > >   Cutoff frequency: 7.04491466139
> >
> > Same here! First I got 40. something in the C++ demo, and when I then
> > after a
> > recompile got 7.0 something I wrongly assumed that they were the same...
>
> I just checked and the previous versions of the demo (pre FunctionSpace)
> also do not give identical results.
> (c++: 7.02634315,  python: 7.04491469, analytical:  7.024814731).
>
> It seems as if the difference is due to the rectangular mesh being uses. 
> In the python demo, the mesh is set to a right diagonal, whereas in the c++
> demo the default (crisscross) is used.
>
> Removing the last parameter of the Rectangle constructor or setting it to 2
> in the python demo confirms this as the result is then identical to that of
> the c++ one.  This also explains why the c++ result is more accurate since
> there are more (smaller) elements in the crisscross mesh.

I did not know about this feature! Thanks for the report.

The demo is fixed now.

Johan