On Mon, Mar 30, 2009 at 8:42 AM, Johannes Ring <[email protected]> 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-sl...@386:dolfin$ du -h demo/mesh/submesh/cpp/dolfin_plot_data.xml > 1.9G demo/mesh/submesh/cpp/dolfin_plot_data.xml > fenics-sl...@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 > [email protected] > http://fenics.org/mailman/listinfo/ufc-dev > -- Ola Skavhaug _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
