dolfin team mailing list archive

[kent-and@xxxxxxxxx]

>
>
> 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?

Yes.

>
>> 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
>
>

I'm happy with this. I guess this would result in a massive saving of
disk space in eg. time dependent problems.