dolfin team mailing list archive

[Andre Massing <massing@xxxxxxxxx>]

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.dev@xxxxxxxxx>
> > *To:* Anders Logg <logg@xxxxxxxxx>
> > *Cc:* dolfin-dev <dolfin@xxxxxxxxxxxxxxxxxxx>
> > *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 <logg@xxxxxxxxx
> > <mailto:logg@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx <mailto:dolfin@xxxxxxxxxxxxxxxxxxx>
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help  : https://help.launchpad.net/ListHelp
> > 
> > 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: This is a digitally signed message part