On Mon, Mar 17, 2008 at 11:54:18PM +0100, [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). > > > > 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, [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 > > > > _______________________________________________ > 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
