[Dune-devel] [Dune-Commit] [Commit] dune-grid - 545f73a: Start working on a backup restore facility in YaspGrid

[Martin Nolte]

Hi Dominic,

you can absolutely use DGF as your backup format. Apart from its block 
structure, there is no limit on how you extend the format.

Let me start with 2 comments:
1. Parameters like keepPhysicalOverlap are usually put into the GridParameters 
block. For optimal use of the DGF parser, it should be put there anyway.
2. Support for tensor product grids is _currently_ lacking. Since YaspGrid can 
now handle those, we should extend the format accordingly - indifferent of 
YaspGrid's internal backup format.

As for parallel DGF: In dune-alugrid, we introduced an extension to dgf to 
read preparitioned grids. Similar to paraview, we use on "master" dgf file 
containing a ALUPARALLEL block, that simply lists the "slave" dgf files for 
each rank. These "slave" dgf files then contain exactly the portion of the 
grid assigned to that processor. This is also described in the dune-alugrid paper.

We could port the "master"-"slave" technique from dune-alugrid to dune-grid 
for this purpose. It would also be good to improve the DGFParser to pass 
around collective communications (instead of the current MPICommunicator).

Best,

Martin


On 10/02/2014 01:41 PM, Dominic Kempf wrote:
> Hey Oliver,
> there is several reasons, that dgf is not suitabel as a backup format:
> - It does not cover all the options that are needed to *fully* restore a YaspGrid.
>    A small example is the parameter keepPhysicalOverlap (bool).
> - It doesnt support tensorproduct grids.
> - With my format, only the coordinates relevant to a processor are stored in that
>    processors backup file. I dont see how such thing could be realized through dgf
>    (seems to me like it takes the same file on every rank)
> Best,
> Dominic
>
> PS: Just read your next mail: Seems like the first point could hold for VTK too,
> if Paraview tries to verify the XML schema. Also, I dont think we want an XML
> parser in dune-grid, do we?
>
> On Thu, Oct 2, 2014 at 1:23 PM, Oliver Sander <sander at igpm.rwth-aachen.de
> <mailto:sander at igpm.rwth-aachen.de>> wrote:
>
>     Am 02.10.2014 um 13:20 schrieb Oliver Sander:
>     > Am 02.10.2014 um 13:10 schrieb Oliver Sander:
>     >> Am 02.10.2014 um 13:02 schrieb Dominic Kempf:
>     >>> Hey Oliver,
>     >>> Yes, I was writing my very own ascii thing. I mad several assumptions when
>     >>> thinking about the format:
>     >>> 1) All grids to be restored were saved through the same facility. For all
>     >>> other uses, one should consider the dgfparser.
>     >>> 2) The amount of data to be stored is rather small (even for tensorproduct
>     >>> grids)
>     >>> 3) The output should be readable by the human eye.
>     >>> With these in mind, I decided, that a self-defined self-explanatory ascii
>     >>> format will be most the most efficient (in the sense of coding time) way to
>     >>> achieve it. If you provide good reasons for a more standard format, I could
>     >>> reconsider though.
>     >>
>     >> Hi Dominic,
>     >> I have no compelling reason for your use case, I am simply not a fan of reinventing
>     >> yet another file format.  Earlier this week I wrote VTK file reading for an application
>     >> of mine, and that was simple and pretty using tinyxml2.
>     >> If you think that "for all other uses, one should consider the dgfparser",
>     >> how about using the dgf format for backup/restore right away?
>     >
>
>     [apologies for the previous empty mail]
>
>     It appears that the vtk format also supports tensor-product grids natively
>     ("RectilinearGrid").  Using that would allow to visualize backup files in
>     Paraview.
>     Best,
>     Oliver
>
>
>      >
>      >
>      >
>      >>
>      >> Best,
>      >> Oliver
>      >>
>      >>
>      >>> Best,
>      >>> Dominic
>      >>>
>      >>> On Thu, Oct 2, 2014 at 12:52 PM, Oliver Sander
>     <sander at igpm.rwth-aachen.de <mailto:sander at igpm.rwth-aachen.de>>
>      >>> wrote:
>      >>>
>      >>>> Hi Dominic,
>      >>>> great you're working on the restoring facility.  From browsing the
>     commit
>      >>>> logs it seems like
>      >>>> you are inventing a new ascii format.  Did you consider something
>      >>>> standard, like XML or similar?
>      >>>> Thanks,
>      >>>> Oliver
>      >>>>
>      >>>>
>      >>>> _______________________________________________
>      >>>> Dune-devel mailing list
>      >>>> Dune-devel at dune-project.org <mailto:Dune-devel at dune-project.org>
>      >>>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>      >>>>
>      >>>>
>      >>>
>      >>
>      >>
>      >>
>      >>
>      >> _______________________________________________
>      >> Dune-devel mailing list
>      >> Dune-devel at dune-project.org <mailto:Dune-devel at dune-project.org>
>      >> http://lists.dune-project.org/mailman/listinfo/dune-devel
>      >>
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > Dune-devel mailing list
>      > Dune-devel at dune-project.org <mailto:Dune-devel at dune-project.org>
>      > http://lists.dune-project.org/mailman/listinfo/dune-devel
>      >
>
>
>
>     _______________________________________________
>     Dune-devel mailing list
>     Dune-devel at dune-project.org <mailto:Dune-devel at dune-project.org>
>     http://lists.dune-project.org/mailman/listinfo/dune-devel
>
>
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel
>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany