dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Mon, Mar 17, 2008 at 5:46 PM, Anders Logg <logg@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).

The solution we use in Sieve is to reconstruct a "right-oriented" closure
from information in the arrows. This is stored just like a section, only its
over arrows, not points. You could also think of an arrow as carrying a
"payload" (this is how Dmitry's system works).

This way you can have whatever system you want in your mesh itself,
but construct oriented simplices when GTS needs them.

  Matt

>  --
>  Anders
>
>
>  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
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener