dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jan 07, 2009 at 12:04:25PM -0500, Shawn Walker wrote:
>
>
> On Wed, 7 Jan 2009, Anders Logg wrote:
>
>> On Wed, Jan 07, 2009 at 04:42:50PM +0000, Garth N. Wells wrote:
>>>
>>>
>>> Anders Logg wrote:
>>>> On Wed, Jan 07, 2009 at 04:00:11PM +0000, Garth N. Wells wrote:
>>>>>
>>>>> kent-and@xxxxxxxxx wrote:
>>>>>>> Martin Sandve Alnæs wrote:
>>>>>>>> On Wed, Jan 7, 2009 at 3:09 PM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>>>>>>>>> Anders Logg wrote:
>>>>>>>>>> On Wed, Jan 07, 2009 at 02:49:17PM +0100, Johan Hake wrote:
>>>>>>>>>>> On Wednesday 07 January 2009 14:28:09 Kent Andre wrote:
>>>>>>>>>>>> It seems to me that the problem is that I have created two different
>>>>>>>>>>>> FunctionSpaces that are actually the same and that the test
>>>>>>>>>>>> in Function is a pointer check.
>>>>>>>>>>>>
>>>>>>>>>>>> One could of course make a better check based on e.g. a signature.
>>>>>>>>>>>> This should be trivial to do. But I will end up with using
>>>>>>>>>>>> a bit more memory than needed. Is this an acceptable solution ?
>>>>>>>>>>> A check for the signature is not enough. Eventually we have to check
>>>>>>>>>>> for the
>>>>>>>>>>> meshes in the two files being the same too.
>>>>>>>>>> Maybe we should add a signature() function for meshes also that
>>>>>>>>>> returns some kind of checksum for the mesh?
>>>>>>>>>>
>>>>>>>>> What's wrong with the approach that I presented? Just read the function
>>>>>>>>> and extract from the function the FunctionSpace and the mesh?
>>>>>>>>>
>>>>>>>>> Garth
>>>>>>>> Reading ten functions from file gives ten meshes in memory.
>>>>>>>>
>>>>>>> This is another issue. Kent's code was reading in one function only.
>>>>>>>
>>>>>>> I have a dislike for reading and writing functions, mainly because of
>>>>>>> the use of signatures and the presence of pre-compiled finite elements
>>>>>>> in DOLFIN (the latter going against the spirit of automated generation).
>>>>>>> The most general approach would be to allow the construction of a
>>>>>>> Function with a FunctionSpace and a GenericVector. The user has to take
>>>>>>> some responsibility in making sure that the DofMap, Mesh, FiniteElement
>>>>>>> and GenericVector match. From a quick look at the code, the only extra
>>>>>>> thing that would be needed is a Function constructor that accepts a
>>>>>>> FunctionSpace and a GenericVector.
>>>>>>>
>>>>>>> Garth
>>>>>>>
>>>>>> In my case I solve a PDE for computing the coefficients in another PDE.
>>>>>> And it is a lot easier to load the coefficient from file than solving the
>>>>>> PDE.
>>>>> OK, so you just need to write the vector containing the coefficients to
>>>>> a file, right?
>>>>>
>>>>>> In my case efficiency is not much of an issue (at least not yet).
>>>>>>
>>>>>> The only problem I see with signatures is that one can use more memory than
>>>>>> needed, but in many situations simplicity is more 'important' than memory.
>>>>>>
>>>>> The memory issue could be designed for. Signatures can change, and for
>>>>> more complicated equations there is inevitably no pre-compiled element.
>>>>>
>>>>> I think that simplicity points in the direction of reading in vectors,
>>>>> meshes and dof maps. We could design it such that writing a function to
>>>>> 'u.xml' would write a number of xml files, e.g. u_mesh.xml,
>>>>> u_dof_map.xml, etc. Then reading u.xml would actaully read in the
>>>>> separate files. Even clever, I guess that they could all go in one file
>>>>> and the XML parser would figure it out, e.g.
>>>>>
>>>>>    Function u;
>>>>>    File file("u.xml");
>>>>>    file << u;
>>>>>
>>>>>    Vector x("u.xml");
>>>>>    Mesh mesh("u.xml");
>>>>>
>>>>> Garth
>>>>
>>>> But then we also have the current discussion about
>>>> reading/representing higher order meshes. How would that work if we
>>>> decided to remove input/output for functions and function spaces?
>>>>
>>>
>>> In practice, we're only talking about removing output of the signature
>>> of the FiniteElement, so I don't see that this would have any more
>>> impact on higher-order meshes than it will on regular functions.
>>>
>>> Garth
>>
>> It will if we want to be able to store a higher-order function space
>> as a function space with a regular mesh and an additional function
>> that stores the layout of the coordinates.
>>
>
> Perhaps that is not the best way to do the higher order mesh coordinates. 
> If we want the higher order mesh data to be a general Function (requiring 
> a FunctionSpace), then I do not see how you can get away from needing the 
> FiniteElement signature associated with it, and possibly other things.
>
> Even if you have the vector of data and the DoFmap, that info must still  
> be used to create a Function/FunctionSpace in the code.  And in order for 
> that to work the DoFmap must be `compatible' with the particular  
> FiniteElement you will be using.  I probably have this wrong, sorry for 
> my confusion.
>
> Another way to do the higher order mesh data would be to keep a little  
> simpler.  Have a vector of data, a DoFmap, and an indicator about the  
> degree of polynomial used.  This would be less general but not bad.  In  
> case of higher-order mesh data, you will ALWAYS use a continuous lagrange 
> finite element.  At least I cannot think of a situation where you would  
> use something else.  Would this not be desirable?

If we decide to remove input/output for Functions and FunctionSpaces
(as I've understood is desirable since we then we don't need to rely
on precompiled elements and dofmaps) then how should we read in a
higher-order mesh from file?

Here's one option:

  Mesh mesh("mesh");
  LagrangeFunctionSpace V(mesh);
  File file("mesh_coordinate_vector.xml");
  Vector x;
  file >> x;
  V.set_coordinates(x);

That might work, but it's a bit long. There should be room for
improvement.

-- 
Anders

Attachment: signature.asc
Description: Digital signature