On Mon, Mar 17, 2008 at 5:46 PM, Anders Logg <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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 > > >> >>> [email protected] > > >> >>> http://www.fenics.org/mailman/listinfo/dolfin-dev > > >> >> _______________________________________________ > > >> >> DOLFIN-dev mailing list > > >> >> [email protected] > > >> >> http://www.fenics.org/mailman/listinfo/dolfin-dev > > >> >> > > >> > > > >> > _______________________________________________ > > >> > DOLFIN-dev mailing list > > >> > [email protected] > > >> > http://www.fenics.org/mailman/listinfo/dolfin-dev > > >> > > > >> > > >> > > >> _______________________________________________ > > >> DOLFIN-dev mailing list > > >> [email protected] > > >> http://www.fenics.org/mailman/listinfo/dolfin-dev > > > _______________________________________________ > > > DOLFIN-dev mailing list > > > [email protected] > > > http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > > > > _______________________________________________ > > DOLFIN-dev mailing list > > [email protected] > > http://www.fenics.org/mailman/listinfo/dolfin-dev > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > 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 _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
