dolfin team mailing list archive

[Maximilian Albert <maximilian.albert@xxxxxxxxx>]

Hi Johan,

thanks for this recipe, that's exactly what I have been searching for
a while because we're having similar problems to Pietro. When you say
you will backport this change to 1.1, does that mean there will be an
updated package in the PPA available sometime soon? Also, until then
is there a similar recipe for how to achieve this with the current (=
1.1.0) version of dolfin?

Many thanks,
Max

2013/1/29 Johan Hake <hake.dev@xxxxxxxxx>:
> 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.
>
> 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