dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

On Mon, Mar 30, 2009 at 8:42 AM, Johannes Ring <johannr@xxxxxxxxx> wrote:
> On Mon, March 30, 2009 07:30, Johan Hake wrote:
>> Looks like the buildbots need some disk cleaning :-)
>>
>> Johan
>>
>> c++ -o
>> src/ufc/ufc_wrap.os -c -fPIC -I/usr/include -I/usr/include/python2.5
>> -Isrc/ufc
>> src/ufc/ufc_wrap.cc
>> /tmp/ccO97jZ3.s: Assembler messages:
>> /tmp/ccO97jZ3.s:30192: Fatal error: can't close src/ufc/ufc_wrap.os: No
>> space
>> left on device
>> scons: *** [src/ufc/ufc_wrap.os] Error 1
>> scons: building terminated because of errors.
>
> Yes, sorry about that. I did some cleanup now.
>
> BTW, I found a quite large xml file in the submesh DOLFIN demo:
>
> fenics-slave@386:dolfin$ du -h demo/mesh/submesh/cpp/dolfin_plot_data.xml
> 1.9G    demo/mesh/submesh/cpp/dolfin_plot_data.xml
> fenics-slave@386:dolfin$
>
> Is this supposed to be this big?

No, we've hit a good old recursion problem. If we have a mesh with a
meshfunction in the data section, we start by saving the mesh. Then
each mesh function is saved in the data section. However, to enable
syntax like:

plot(mesh_function)

in c++, we save the mesh when saving the meshfunction. This mesh has a
data section, and we're back to square one.

I don't know exactly how to solve this. Perhaps a keyword argument to
write, spesifying if the mesh should be written to file when saving
the meshfunction could solve this.

Ola

>
> Johannes
>
>
> _______________________________________________
> UFC-dev mailing list
> UFC-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufc-dev
>



-- 
Ola Skavhaug