https://mooseframework.inl.gov
Public Types | Public Member Functions | Static Public Member Functions | Public Attributes | Static Public Attributes | Protected Member Functions | Static Protected Member Functions | Protected Attributes | List of all members
StochasticResultsAction Class Reference

This action is a crutch that gets around a construction and initialSetup execution order of operations problem between three types of objects. More...

#include <StochasticResultsAction.h>

Inheritance diagram for StochasticResultsAction:
[legend]

Public Types

typedef DataFileName DataFileParameterType
 

Public Member Functions

 StochasticResultsAction (const InputParameters &params)
 
virtual void act () override
 
void timedAct ()
 
virtual void addRelationshipManagers (Moose::RelationshipManagerType when_type)
 
MooseObjectName uniqueActionName () const
 
const std::string & specificTaskName () const
 
const std::set< std::string > & getAllTasks () const
 
void appendTask (const std::string &task)
 
MooseApp & getMooseApp () const
 
const std::string & type () const
 
virtual const std::string & name () const
 
std::string typeAndName () const
 
std::string errorPrefix (const std::string &error_type) const
 
void callMooseError (std::string msg, const bool with_prefix) const
 
MooseObjectParameterName uniqueParameterName (const std::string &parameter_name) const
 
const InputParameters & parameters () const
 
MooseObjectName uniqueName () const
 
const T & getParam (const std::string &name) const
 
std::vector< std::pair< T1, T2 > > getParam (const std::string &param1, const std::string &param2) const
 
const T * queryParam (const std::string &name) const
 
const T & getRenamedParam (const std::string &old_name, const std::string &new_name) const
 
T getCheckedPointerParam (const std::string &name, const std::string &error_string="") const
 
bool isParamValid (const std::string &name) const
 
bool isParamSetByUser (const std::string &nm) const
 
void paramError (const std::string &param, Args... args) const
 
void paramWarning (const std::string &param, Args... args) const
 
void paramInfo (const std::string &param, Args... args) const
 
void connectControllableParams (const std::string &parameter, const std::string &object_type, const std::string &object_name, const std::string &object_parameter) const
 
void mooseError (Args &&... args) const
 
void mooseErrorNonPrefixed (Args &&... args) const
 
void mooseDocumentedError (const std::string &repo_name, const unsigned int issue_num, Args &&... args) const
 
void mooseWarning (Args &&... args) const
 
void mooseWarningNonPrefixed (Args &&... args) const
 
void mooseDeprecated (Args &&... args) const
 
void mooseInfo (Args &&... args) const
 
std::string getDataFileName (const std::string &param) const
 
std::string getDataFileNameByName (const std::string &relative_path) const
 
std::string getDataFilePath (const std::string &relative_path) const
 
PerfGraph & perfGraph ()
 
const Parallel::Communicator & comm () const
 
processor_id_type n_processors () const
 
processor_id_type processor_id () const
 

Static Public Member Functions

static InputParameters validParams ()
 

Public Attributes

const ConsoleStream _console
 

Static Public Attributes

static constexpr auto SYSTEM
 
static constexpr auto NAME
 

Protected Member Functions

bool addRelationshipManagers (Moose::RelationshipManagerType when_type, const InputParameters &moose_object_pars)
 
void associateWithParameter (const std::string &param_name, InputParameters &params) const
 
void associateWithParameter (const InputParameters &from_params, const std::string &param_name, InputParameters &params) const
 
const T & getMeshProperty (const std::string &data_name, const std::string &prefix)
 
const T & getMeshProperty (const std::string &data_name)
 
bool hasMeshProperty (const std::string &data_name, const std::string &prefix) const
 
bool hasMeshProperty (const std::string &data_name, const std::string &prefix) const
 
bool hasMeshProperty (const std::string &data_name) const
 
bool hasMeshProperty (const std::string &data_name) const
 
std::string meshPropertyName (const std::string &data_name) const
 
PerfID registerTimedSection (const std::string &section_name, const unsigned int level) const
 
PerfID registerTimedSection (const std::string &section_name, const unsigned int level, const std::string &live_message, const bool print_dots=true) const
 
std::string timedSectionName (const std::string &section_name) const
 

Static Protected Member Functions

static std::string meshPropertyName (const std::string &data_name, const std::string &prefix)
 

Protected Attributes

std::string _registered_identifier
 
std::string _specific_task_name
 
std::set< std::string > _all_tasks
 
ActionWarehouse & _awh
 
const std::string & _current_task
 
std::shared_ptr< MooseMesh > & _mesh
 
std::shared_ptr< MooseMesh > & _displaced_mesh
 
std::shared_ptr< FEProblemBase > & _problem
 
PerfID _act_timer
 
MooseApp & _app
 
const std::string _type
 
const std::string _name
 
const InputParameters & _pars
 
Factory & _factory
 
ActionFactory & _action_factory
 
MooseApp & _pg_moose_app
 
const std::string _prefix
 
const Parallel::Communicator & _communicator
 

Detailed Description

This action is a crutch that gets around a construction and initialSetup execution order of operations problem between three types of objects.

SPT = SamplerPostprocessorTransfer (MultiappTransfer) SR = StochasticResults (VectorPostprocessor) PCT = PolynomialChaosTrainer (GeneralUserObject)

PROBLEM

Here is the scenario (see surrogats/load_store/train.i)

  1. The following objects and data needed:

    SPT: transfers PP values from sub-applications to the the master SR. The names of the vectors on the master are dictated by the PP names being captured from the sub-app. SR: stores vectors of stochastic data from the SPT PCT: uses the data from the SR to train a reduced order model

    A problem arises because the SPT dictates the what vectors are declared in the SR.

  2. Construction

The following construction order exists as dictated by MOOSE: PCT, SPT, SR

Therefore, the SPT must wait until initialSetup to declare the vectors on the SR because the SR is not constructed until after the SPT.

The PCT needs to query information about the data vectors in SR (e.g., size, is distributed), which needs to happen in initialSetup because the SR is not constructed until after the PCT.

  1. initialSetup

The following initialSetup order exists as dictated by MOOSE: PCT, SR, SPT

As mentioned above the SPT::initialSetup creates vectors in the SR. However, the PCT needs the vectors in-place during initialSetup. Therefore, the current API doesn't meet the needs for this workflow.

SOLUTION

The first implementation of this relationship required that both the SPT and the SR required the sampe Sampler object. The name of the Sampler was used as the name of the result vectors in the SR. This worked, but limited the ability to retrieve more than one PP value from a sub-application. Multiple values were only possible if the sub-application that was computing them was based on another Sampler object. That scenario is far less likely then trying to collect more the one PP value from a sub-application. Furthermore, the sampler name is irrelevant to the data being captured from the sub-applications.

The goal is to have this SPT be able to grab many PP values from a sub-application and store them in vectors in SR using the PP name as the name of the vector. This basic goal can be accomplished by using the initialSetup functions of the SPT and SRT, until the results are needed by another object, such as a Trainer, as shown above.

There are a few possible solutions. It is important to state that the PCT should always operate on generic VPP data to allow for training data to come from any VPP objects. So, solutions that require PCT to have knowledge of the SR are not considered.

  1. Construct the SR before the SPT. This allows for the SPT to declare the vectors at construction, thus they are available during the intialSetup of other objects. The downside is that this will require a special Action for the SR construction.
  2. The PCT could use initialize() for querying the SR vectors. The downside is that the PCT is an example of a user-created surrogate trainer. Requiring the use of initialize() to get things working is not desirable for users code.
  3. Declare the vectors in the constructor of the SR. The downside is that the vector names are dictated by the SPT "from_postprocessor" input parameter, so there is no direct way to get them up front.
  4. Use an Action to set the a parameter on the SR based on a parameter for SPT.

The solution implemented takes the approach of (4). When the SPT is created it caches the PP names associated with the SR object that will be populated in this action. Then when the SR is created it declares the vectors in the cache.

Definition at line 88 of file StochasticResultsAction.h.

Constructor & Destructor Documentation

◆ StochasticResultsAction()

StochasticResultsAction::StochasticResultsAction ( const InputParameters &  params)

Definition at line 31 of file StochasticResultsAction.C.

31 : Action(params) {}
Action::Action
Action(const InputParameters &parameters)

Member Function Documentation

◆ act()

void StochasticResultsAction::act ( )
overridevirtual

Implements Action.

Definition at line 34 of file StochasticResultsAction.C.

35 {
36  if (_current_task == "declare_stochastic_results_vectors")
37  {
38  for (std::shared_ptr<Transfer> & transfer_ptr :
39  _problem->getTransfers(Transfer::DIRECTION::FROM_MULTIAPP))
40  {
41  auto ptr = std::dynamic_pointer_cast<SamplerPostprocessorTransfer>(transfer_ptr);
42  if (ptr != nullptr)
43  {
44  const auto & result_name =
45  ptr->getParam<VectorPostprocessorName>("to_vector_postprocessor");
46  const std::vector<VectorPostprocessorName> & vpp_names = ptr->vectorNames();
47 
48  // Get the StochasticResults storage object, get it by base class to allow for better
49  // type check error message
50  auto & uo = _problem->getUserObject<UserObject>(result_name);
51  auto * results = dynamic_cast<StochasticResults *>(&uo);
52  if (!results)
53  mooseError("The object prescribed by the 'to_vector_postprocessor' parameter in ",
54  ptr->name(),
55  " must be a 'StochasticResults' object.");
56  for (const auto & vpp_name : vpp_names)
57  results->initVector(vpp_name);
58  }
59  }
60  }
61 }
SamplerPostprocessorTransfer
Transfer Postprocessor from sub-applications to a VectorPostprocessor on the master application...
Definition: SamplerPostprocessorTransfer.h:25
StochasticResults
A tool for output Sampler data.
Definition: StochasticResults.h:30
MultiAppTransfer::getParam
const T & getParam(const std::string &name) const
Action::_current_task
const std::string & _current_task
Action::mooseError
void mooseError(Args &&... args) const
Action::_problem
std::shared_ptr< FEProblemBase > & _problem

◆ validParams()

InputParameters StochasticResultsAction::validParams ( )
static

Definition at line 23 of file StochasticResultsAction.C.

24 {
25  InputParameters params = Action::validParams();
26  params.addClassDescription("Action for performing initialization of StochasticResults vectors "
27  "based on SamplerPostprocessorTransfer.");
28  return params;
29 }
Action::validParams
static InputParameters validParams()
InputParameters::addClassDescription
void addClassDescription(const std::string &doc_string)
The documentation for this class was generated from the following files:
Generated on Thu Jul 17 2025 01:51:44 for https://mooseframework.inl.gov by   doxygen 1.8.14