dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

The fix is not released. So you need to check out the 1.1.x branch.

  bzr branch lp:dolfin/1.1.x dolfin-1.1.x

and compiled from source.

An alternative would be to make a point release from the 1.1.x branch.
Then that could propagate into an updated ppa package.

What do the other developer says?

Johan

On 01/30/2013 07:10 PM, Maximilian Albert wrote:
> 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