dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Mar 17, 2008 at 11:54:18PM +0100, cosby@xxxxxxxxx wrote:
> > Yes, the mesh ordering used in DOLFIN (intentionally) screws up any
> > ordering, like all cells being "right-oriented" or similar.
> >
> > If this is a problem for GTS, we need to do something about the GTS
> > interface (not the mesh).
> >
> 
> hhmm, ok.
> Does this reordering mean that the cell numbers before and after differ ?
> If not, then I'll just do the cell searching before it is reordered and
> then pass the cell number to the eval function as well.

The cell numbers will not change, only the ordering of vertices in
each cell.

-- 
Anders


> Kristen
> 
> 
> >
> >
> > On Mon, Mar 17, 2008 at 11:19:52PM +0100, cosby@xxxxxxxxx wrote:
> >> I assume you meant mesh.order(), correct ?
> >> In fact, by ordering the mesh I also screw up the local cell searching.
> >> Is there something wrong with my mesh. I generated it with gmsh.
> >> I have been wondering what the color (blue and black) of the mesh means
> >> when you plot it. Before ordering the mesh, all outward pointing facets
> >> are blue.
> >> After ordering the color of the facets of the boundary mesh are both
> >> black
> >> and blue (maybe have a look at the
> >> mesh:http://www.fys.ku.dk/~cosby/mesh.xml , notice 60 MB).
> >>
> >> Kristen
> >>
> >>
> >> > One problem might be that the mesh may get reordered (renumbered)
> >> > during assembly.
> >> >
> >> > Do you get the same problem if you do mesh.sort() the first thing you
> >> > do before doing anything else?
> >> >
> >> >
> >> >
> >> > On Mon, Mar 17, 2008 at 10:08:21PM +0100, Dag Lindbo wrote:
> >> >> Send me some code and I'll try to figure it out.
> >> >>
> >> >>   Dag
> >> >>
> >> >> > I have experienced some strange behavior with the
> >> >> IntersectionDetector.
> >> >> > When I carry out the cell searching as the first thing after the
> >> mesh
> >> >> > variable has been created, the searching is successful. However, if
> >> I
> >> >> > solve a pde and use the eval function, or a locally created
> >> >> intersection
> >> >> > detector, some points are simply not found.
> >> >> > Has anyone else experienced this (using the python wrappings) ?
> >> >> >
> >> >> > Kristen
> >> >> >
> >> >> >
> >> >> >
> >> >> >> On Mon, Mar 17, 2008 at 09:19:02PM +0100, cosby@xxxxxxxxx wrote:
> >> >> >>> Would it work if I transfered the updated files in
> >> dolfin/function/
> >> >> to
> >> >> >>> version 0.7.2 or are the any new changes that would break
> >> >> dependencies
> >> >> >>> on
> >> >> >>> these files ?
> >> >> >>>
> >> >> >>> Kristen
> >> >> >>
> >> >> >> Don't know, you'll have to try and see what happens...
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>>
> >> >> >>> > On Mon, Mar 17, 2008 at 05:04:43PM +0100, Kristen Kaasbjerg
> >> wrote:
> >> >> >>> >> Anders Logg wrote:
> >> >> >>> >> > It's now possible to evaluate functions at arbitrary points
> >> >> inside
> >> >> >>> the
> >> >> >>> >> > mesh where the function is defined. If evaluated outside,
> >> you
> >> >> >>> should
> >> >> >>> >> > get an informative exception.
> >> >> >>> >> >
> >> >> >>> >> > Thanks to Kristen Kaasbjerg for providing the code.
> >> >> >>> >> >
> >> >> >>> >> > There's a demo in demo/function/. The C++ version seems to
> >> work
> >> >> >>> fine,
> >> >> >>> >> > but the Python version is broken. The problem is that FFC
> >> JIT
> >> >> does
> >> >> >>> not
> >> >> >>> >> > generate the code for evaluate_basis (you should get an
> >> >> >>> informative
> >> >> >>> >> > exception about this if you install the very latest FFC).
> >> >> >>> Switching
> >> >> >>> it
> >> >> >>> >> > on is a simple fix, but we might want to avoid that.
> >> >> >>> >> >
> >> >> >>> >> > I don't know how to solve this. Maybe we should always
> >> generate
> >> >> >>> code
> >> >> >>> >> > for evalute_basis, but that might slow down the overall
> >> >> >>> performance
> >> >> >>> >> > of the JIT compiler. Suggestions?
> >> >> >>> >> >
> >> >> >>> >> > Please test it and see if it works. Would be nice if Dag
> >> could
> >> >> run
> >> >> >>> >> > the benchmarks again to confirm that I didn't mess anything
> >> up.
> >> >> >>> >> >
> >> >> >>> >> >
> >> >> >>> >> Note that Dag Lindbo also contributed to the development of
> >> the
> >> >> code
> >> >> >>> to
> >> >> >>> >> the eval function !
> >> >> >>> >> So thanks to him as weel.
> >> >> >>> >
> >> >> >>> > Yes! My fault.
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> 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