Writing a database writer


A database writer is an optional part of a database plugin. If you implement this part of a database plugin, then a new option will appear in the "Export Database" feature to export data using your plugin type.


You tell VisIt that your database plugin can also write data through the xmledit program. You do this by checking the "File format can also write data" button to on.


There are four basic methods for writing a database writer. You must implement each of these methods, although any of the methods can effectively be no-ops (i.e. {;}).

NOTE: if you run the xml2avt tool, the header file and a skeleton of the .C file will be autogenerated. That is the easiest way to start. Note that your database writer will inherit from avtDatabaseWriter. If you want to get specifics on how your methods are called, you can look at /src/avt/Pipeline/Sinks/avtDatabaseWriter.C, which calls each of your methods.

The methods and their signatures are:

  • void OpenFile(const std::string &, int);
  • void WriteHeaders(const avtDatabaseMetaData *, std::vector<std::string>&,std::vector<std::string>&, std::vector<std::string> &);
  • void WriteChunk(vtkDataSet *, int);
  • void CloseFile(void);


This is the first method called. It tells you what the stem for the file name is and also tells you how many total chunks will be. In parallel, keep in mind that this is called on every processor.

It is totally viable to simply store the file name and the number of chunks as data members in your writer and do the actual opening of files in the WriteHeaders method.


This is the second method to be called. It tells you about the data set you are writing. Note that the meta-data is taken from the input file, and if operators were applied, then the meta-data may have changed. For example, a 3D data set may have been sliced and become 2D. But you will be told that the data set is 3D. This issue has not been addressed yet.


This is called for each "domain"/"chunk" in the data set. Each processor can have this method be called 0 or more times and the total number of calls over all processors will be the number of chunks registered in OpenFile.


An opportunity for you to clean up. This may be a no-op for simple file formats.