VectorPostprocessors Outputting Things Other Than Reals

[friedmud]

Rationale

Sometimes it would be nice to fill columns up with std::string or int or bool... instead of Real

Description

To implement this we would need a system similar to declareProperty<>() in the Material system. It might be worth factoring that out.

We would make declareVector<>() templated on the type the column is going to hold.

Impact

Could have some impact for existing users of VPP because the interface will change.

[aeslaughter]

I think I will need this for the stochastic tools for adding row headings.

[aeslaughter]

The demand for "other" types of data seem to be growing. At the simplest end row names are needed. But, as we add capability for computing statistics, confidence, and sensitivity the ability to store tables and matrices of data would be useful. There is also plans to support reading in experimental data for analysis and comparison, which might require more complex data structures.

I started generalizing VPP vectors to support multiple types. When doing this I realized that we could use this concept to generalize both PPs and VPPs. I am proposing that we replace PP and VPP objects with a "Reporter" object (I am up for other names, but I like this one because of my history with this idea). In practice a Reporter will operate nearly the same as VPP, but instead be able to declare other types as well, including single Reals.

In a Reporter you would declare data and get back a reference, just like VPPs.

decalreValue<Real>("foo") decalreValue<std::vector<Real>>("bar")

In other objects you would get the values, just like VPPs.

getReporterValue<Real>("object name", "foo") getReporterValue<std::vector<Real>>("object name", "bar")

I think we should limit the types via explicit instantiation to avoid losing control of parallel optimizations such as the distributed and scatter capability for vectors. The Reporter will still be an aggregate value calculator. It computes a value for the entire simulation, but the value can be non-scalar and it can compute many.

I also plan on adding the ability to specialize operations for specific types. For example for std::vector types, when declaring you will be able to set if the vector is to be replicated or if it is distributed or scattered, etc. to match our current capabilities.

My implementation plan:

1. create the basic Reporter objects, closely mimicking the VPP implementation, and support scalar types and std::vector types.
2. support CSV output of Reporter types for Real and std::vector
3. deprecate PP/VPP objects and replace with Reporter objects
4. develop a JSON output object that will allow for more complex output structures, this will likely mimic the dataLoad/Store design to allow for arbitrary types to be output (this is another issue/discussion)

@idaholab/moose-team How does this sound? I have funding for this and I fell it will be an improvement for the framework. Basically, the VPP design is solid and it can be generalized to improve PPs and more.

[permcody]

I'm open to the idea of expanding post processor capabilities, but I think we need to discuss the design in detail before you start any work here.

If you move to templated types, you are going to increase the complexity of the backing data structure storing these types and you will end up reimplementing the material system (which is itself a pretty big mess and one of the things we HAVE to work on this year - it's in our Multiphysics milestone, remember?). In fact with the proposal you have here, the Reporter object could potentially be more complex than the material system with the added complexity of not having a tight mapping to the mesh and offering differing requirements on parallel behavior.

So before you start here, we really should look at whether it makes sense to try to reuse parts of the material data system for the "reporter" system. Also this might still fall short of the mark when it comes to storing more general data. What if you wanted a table with strings and data? @friedmud made that "variant table" object but there were some limitations on its use so it couldn't directly be applied here. I think the path to storing a table in the VPP system is shorter than reimplementing the whole system. Are you sure you need generic types or would having a table meet all your needs? Let's make sure we understand the requirement. Also is the table related to mesh in any way?

Let's just make sure we have a clear goal and buy-in before you get too far down this path and into the weeds.

[amjokisaari]

I can see the utility here. It would be a nice benefit to be able to output other types of information, like a tensor or complex quantity. Also, it would be a good usability improvement such that related information (nonlinear / linear iterations or statistical quantities like mean/std dev/skew) are in one block in the input file.

I appreciate Cody's comments about backend issues - not my area of expertise!

[aeslaughter]

@permcody I was able to store arbitrary types within the existing VPP system with minimal effort. The actual storage of the data is handled by the restart system already. The design of the VPP objects is quite good and almost capable of this already. So, the Reporter would be very close to VPPs.

The values to be computed are still an aggregate calculation, nothing tied to the mesh. I definitely want to limit the types that are allowed, we can always grow them.

[lindsayad]

I like templates

On Fri, May 15, 2020 at 8:31 AM Andrew E Slaughter notifications@github.com wrote:

@permcody https://github.com/permcody I was able to store arbitrary types within the existing VPP system with minimal effort. The actual storage of the data is handled by the restart system already. The design of the VPP objects is quite good and almost capable of this already. So, the Reporter would be very close to VPPs.

The values to be computed are still an aggregate calculation, nothing tied to the mesh. I definitely want to limit the types that are allowed, we can always grow them.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/11323#issuecomment-629312845, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOGA4DWHRUSCP2BWBHMEJLRRVN6NANCNFSM4E3R5OUQ .

[aeslaughter]

The problem I am seeing is that while it is possible to output the desired data for sensitivity and confidence level intervals within VPPs, the resulting vectors are crazy complex and meaningless without a lot of documentation and tools to convert them into a more usable format. Rather than creating additional python based processing tools I would rather improve the output within MOOSE, so you don't have to run a script to view your output.

[rwcarlsen]

I think it could be good and useful to be able to output more structured information from the simulation (e.g. json) like this. I've never been a particular fan of the limited real/vector nature of the postprocessors - often users are trying to get some sort of table-like output and vectorpostprocessors are an awkward way to do that. I don't like the name "reporter" and neither "postprocessor" actually. "Reporter" implies something output-ish and conveys none of the not-mesh-specific meaning. I like the word "aggregate" - maybe it could be the Aggregator system?

[aeslaughter]

I like "Aggregator", except it is too hard to spell. I will never be able to type getAggregatorValue without messing up a few times.

[aeslaughter]

Here is an output example we have now: Results. This is a fairly simple example with 4 input variables and two output variables. The file in Listing 1 is actually three tables of data. In the near future these calculations will included confidence levels as well so each of the three tables will include another table for each confidence level computed usually at least two, but probably more.

If this was in JSON format the data could at least contain the meta data like the input variable names and index name (first, second, total). As of now, in order to understand the output you must have the input file. If you lose or change your input file the output is useless.

[zachmprince]

I like the idea, since communicating results has always been a difficulty for me in moose. My one concern is whether this idea will make implementation of simple "Reporters" more difficult. Will the implementation of current high-level PPs and VPPs look relatively the same?

[aeslaughter]

The interface will be nearly identical to VPPs. The difference being you have to use template arguments for the declare/get methods.

[aeslaughter]

I think I can have a prototype ready in a few days. I will make it as simple as I can just to show off the concept, after that we can make a decision to keep going or not.

[friedmud]

I'll wait to see what this looks like in the end - but I hope the VPP system doesn't change much. It is in heavy use by many people for many purposes.

@rwcarlsen I'm not sure I understand your comment. VPPs produce table output. Can you expand on what you're looking for?

VPPs don't have to be the end-all solution. We can certainly add more things to fill other gaps - but I think VPPs do a good job for their intended purpose!

[zachmprince]

Let's call this done with the Reporter system