FormattedTable needs refactoring

[aeslaughter]

Once we finalize what we want to do for VectorPostprocessor output the FormattedTable object needs to be reformatted. It seems to be getting messy, I just added some more mess with #3229.

I will do this, but just want us to all agree on what the VectorPostprocessor output will look like before I start.

[aeslaughter]

Here is my design proposal. First, I think we should make it a MooseObject to give us the InputParameters interface. This would allow all of the settings such as the terminal width, output precision, delimiter, etc... to be specified and stored via the InputParameters, which will eliminate the multitude of set methods for each of the parameters. If we don't make it a MooseObject I still think we should user InputParameters for the settings and provide template setters/getters.

class FormattedTable : public MooseObject // I will discuss this at the end
{
public:

// Allow for the independent variable to be set at construction; default to time, but allow it
// to be set to something else, "x", "distance", ....
FormattedTable(std::string independent_variable = "time")

// This stays the same, except time is now more generic. However, this will
// include a column_width calculation that computes the necessary column width for the
// given name and data, using the supplied precision settings and column name
addData(std::string name, Real value, Real independent_value)

// Printing complete table and partial table to stream
print(std::ostream & out)
print(std::ostream & out, unsigned int last_n_entries, std::setstd::string column_names)

// Writing to files, the type of write GNU, CSV, ... handled via filename extension
// I also think we should add a pyplot script builder similar to what we have for GNU
write(std::string filename)
write(ExodusII_IO)
write(VTK_IO) // this should be possible with Field data in VTK format

protected:

printTablePiece(...)
writeGnuPlot(...)
writeCSV(...)

};

[aeslaughter]

On another note, do we want to be able to print VectorPostprocessor tables to the screen? If so, what should we do to minimize major screen dump. Perhaps, we print the first few values and the last few with ... in the middle.

distance value
0 1
1 2
2 3
... ...
1000 4
1001 5

[friedmud]

I vote against making it a MooseObject. That would make it much less flexible and harder to unit test.

In light of that I would also vote against using input parameters. This type of thing is a pure CS project and it should conform to good object-oriented coding practices.

[friedmud]

I do agree that it needs to be refactored though!

[permcody]

I recently refactored FormattedTable quite a bit (#10199). It's properly stateful now so it can be stored on disk and recovered. It no longer writes entire files when asked to append. It also has a new addData interface specifically to handle VectorPostprocessors (i.e. add a Column Vector). I stopped short of making the underlying data structure a vector of vectors though which might be the final "nice" improvement. It has been refactors so that the outer part of the structure is a vector, but the inner part is still a map. I think I'll close this ticket and allow someone to open a new specific ticket for something that needs to be fixed if it's needed.