On Tue, 2013-01-29 at 23:14 +0100, Johan Hake wrote: > On 01/29/2013 10:00 PM, Pietro Maximoff wrote: > > Hi > > > > Johan, thanks for adding this. > > > > This function is particularly important for me as currently, all my code > > is broken in Fenics 1.1. > > > > I need to be able to associate each component of a 'solution' vector > > with a coordinate value, carry out some processing and store data back > > in exactly the same order in the 'same' or similar solution vector. > > compute_vertex_values() doesn't give this functionality but > > tabulate_vertex_map() does this!?! > > Yes. I will soon rename the method to vertex_to_dof_map, however. Then > it will be: > > vertex_to_dof = V.dofmap().vertex_to_dof_map(mesh) > > # Use num coordinates to work in parallel > data = np.zero(len(mesh.num_coordinates())) > data[vertex_to_dof] = u.vector().array() > > # Do stuff on data > > # Put data back > u.vector().set_local(data[vertex_to_dof]) > > > How can I get my hands on it? Do I just use dorsal with stable_build set > > to false? > > I guess so. Once I have changed the name I will back port it to 1.1. It > might be safer to work with that instead of trunk right now, as trunk is > undergoing heavy development. > > I am not sure how to install the latest revision of the lp:dolfin/1.1.x > branch using dorsal. You can get the latest 1.1.x code by: > > bzr branch lp:dolfin/1.1.x dolfin-1.1.x > > It might be just to copy the dorsal_configure and dorsal_build scripts > to the dolfin-1.1.x dir and run them, as they should contain all > information required to build and configure dolfin.
<thread-hijacking> Just as I side note, I am hacking dorsal a bit right now on my laptop to add exactly this type of extra convenience (maybe you want to have a look at https://blueprints.launchpad.net/dorsal/+spec/mult-branch-support ) Not completely sure about the best syntax, right now it would be possible (among other things) to specify your branches by simply adding something like UFC_BRANCH=lp:ufc/2.1.x UFL_BRANCH=lp:ufl/1.1.x FFC_BRANCH=lp:ffc/1.1.x VIPER_BRANCH=lp:fenics-viper/1.1.x INSTANT_BRANCH=lp:instant/1.1.x DOLFIN_BRANCH=lp:dolfin/1.1.x to your local.cfg in the dorsal folder. </thread-hijacking> -- Andre > > Johan > > > Pietro > > > > ------------------------------------------------------------------------ > > *From:* Johan Hake <hake....@gmail.com> > > *To:* Anders Logg <l...@simula.no> > > *Cc:* dolfin-dev <dolfin@lists.launchpad.net> > > *Sent:* Monday, January 28, 2013 10:52 PM > > *Subject:* Re: [Dolfin] DofMap.tabulate_vertex_map > > > > On 01/28/2013 11:36 PM, Anders Logg wrote: > >> On Mon, Jan 28, 2013 at 10:33:15PM +0000, Garth N. Wells wrote: > >>> On 28 January 2013 22:27, Anders Logg <l...@simula.no > > <mailto:l...@simula.no>> wrote: > >>>> On Mon, Jan 28, 2013 at 11:19:13PM +0100, Johan Hake wrote: > >>>>> On 01/28/2013 11:08 PM, Anders Logg wrote: > >>>>>> On Mon, Jan 28, 2013 at 10:37:46PM +0100, Johan Hake wrote: > >>>>>>> On 01/28/2013 10:22 PM, Anders Logg wrote: > >>>>>>>> On Mon, Jan 28, 2013 at 10:10:40PM +0100, Johan Hake wrote: > >>>>>>>>> Hello! > >>>>>>>>> > >>>>>>>>> I have now added a method to DofMap, which tabulate a map between > >>>>>>>>> vertices and dofs. It will only work for DofMaps with dofs on > > vertices. > >>>>>>>>> So basically for any CG 1 FunctionSpaces and will raise error > > else wise. > >>>>>>>>> > >>>>>>>>> Usage: > >>>>>>>>> > >>>>>>>>> from dolfin import * > >>>>>>>>> import numpy as np > >>>>>>>>> mesh = UnitSquareMesh(10,10) > >>>>>>>>> V = VectorFunctionSpace(mesh, "CG", 1) > >>>>>>>>> u = Function(V) > >>>>>>>>> u.interpolate(Constant((1,2))) > >>>>>>>>> vert_values = np.zeros(mesh.num_vertices()*2) > >>>>>>>>> vert_values[V.dofmap().tabulate_vertex_map(mesh)] = \ > >>>>>>>>> u.vector().array() > >>>>>>>>> print vert_values > >>>>>>>>> > >>>>>>>>> In parallel the map will follow the local dofs. This means that > > some > >>>>>>>>> values in vert_values above will still be 0. The 0 values will then > >>>>>>>>> correspond to vertex values which are owned by another process. > >>>>>>>>> > >>>>>>>>> In C++ the method returns a std::vector<std::size_t>. > >>>>>>>>> > >>>>>>>>> Questions: > >>>>>>>>> Does the name "tabulate_vertex_map" work? > >>>>>>>> > >>>>>>>> Sounds ok. > >>>>>>>> > >>>>>>>>> Should a version of this method exist in other classes. > > FunctionSpace, > >>>>>>>>> Function (without the mesh argument of course)? > >>>>>>>> > >>>>>>>> Yes, would be good to have for convenience. > >>>>>>>> > >>>>>>>> What is the relation to Function::compute_vertex_values? > >>>>>>> > >>>>>>> compute_vertex_values works on any GenericFunction. However, for all > >>>>>>> Functions from CG 1 families I guess one could use this map to just > >>>>>>> tabulate the entries. > >>>>>> > >>>>>> What does the tabulate_vertex_map method do which > >>>>>> compute_vertex_values doesn't? Enable writing to dofs? > >>>>> > >>>>> RTFC! ;) > >>>>> > >>>>> tabulate_vertex_map only computes a map based on the prior knowledge of > >>>>> the dofs coinciding with the vertices. compute_vertex_values are much > >>>>> more general and used > >>>>> > >>>>> element.interpolate_vertex_values > >>>>> > >>>>> to do the heavy lifting. > >>>> > >>>> Yes, so why is tabulate_vertex_map needed, if compute_vertex_values > >>>> already computes the vertex values and is much more general? > >>>> > >>>>> I see tabulate_vertex_map as a convenience mapping for users who want > >>>>> their data on a vertex based format, or users who want data which > >>>>> resides on vertices into dolfin la structures. > >>>> > >>>> What is the use case? If it is for plotting or postprocessing, then > >>>> compute_vertex_values should be enough. > >>>> > >>>> Or is the intention to use it for modifying values of CG1 functions > >>>> from the outside? > >>>> > >>> > >>> I don't think that it's required, but I guess Johan is adding it by > >>> popular demand. > > > > ;) > > > > Well I have a similar mapping in my own tools, and instead of giving > > that code away all the freaking time I pushed it to DOLFIN. My code was > > also Python only and recently we got some C++ request. > > > >> I'm not objecting to it. I just came to think about the > >> compute_vertex_values function and it should be enough to cover most > >> of the use cases that are the background for the popular demand: users > >> of Hans Petter's tutorial who want to get the vertex values on a > >> regular grid for postprocessing in external software like MATLAB. > > > > I think the compute_vertex_values could fill the purpose of most use > > cases, but I think having the mapping available could be nice and > > convenient. > > > > Even if we discourage indexing into vectors, people tend to ignore it, > > because it is often just the natural way to do stuff. Especially for > > Functions in CG1 family spaces. By forcing a user to use local process > > data for all things numpy, we can be useful for both numpy and HPC folks. > > > > Johan > > > >> -- > >> Anders > >> > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dolfin > > Post to : dolfin@lists.launchpad.net <mailto:dolfin@lists.launchpad.net> > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp > > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : dolfin@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
