Can we output some simulation information earlier?

[YaqiWang]

I have some customed actions which output some important information. But these information come out earlier than the framework information to the console. Can we output some simulation information a bit earlier with the following patch?

diff --git a/framework/src/outputs/Console.C b/framework/src/outputs/Console.C
index 9938789..84ecfee 100644
--- a/framework/src/outputs/Console.C
+++ b/framework/src/outputs/Console.C
@@ -149,6 +149,26 @@ Console::Console(const std::string & name, InputParameters parameters) :
         Moose::_color_console = false;
     }
   }
+  // Framework information
+  std::stringstream oss;
+  if (_app.getSystemInfo() != NULL)
+    oss << _app.getSystemInfo()->getInfo();
+
+  if (_problem_ptr->legacyUoAuxComputation() || _problem_ptr->legacyUoInitialization())
+  {
+    oss << "LEGACY MODES ENABLED:\n";
+    if (_problem_ptr->legacyUoAuxComputation())
+      oss << "  Computing EXEC_RESIDUAL AuxKernel types when any UserObject type is executed.\n";
+    if (_problem_ptr->legacyUoInitialization())
+      oss << "  Computing all UserObjects during initial setup.\n";
+  }
+
+  oss << std::left << '\n'
+      << "Parallelism:\n"
+      << std::setw(_field_width) << "  Num Processors: " << static_cast<std::size_t>(n_processors()) << '\n'
+      << std::setw(_field_width) << "  Num Threads: " << static_cast<std::size_t>(n_threads()) << '\n'
+      << '\n';
+  write(oss.str());
 }

 Console::~Console()
@@ -547,25 +567,6 @@ Console::outputSystemInformation()

   std::stringstream oss;

-  // Framework information
-  if (_app.getSystemInfo() != NULL)
-    oss << _app.getSystemInfo()->getInfo();
-
-  if (_problem_ptr->legacyUoAuxComputation() || _problem_ptr->legacyUoInitialization())
-  {
-    oss << "LEGACY MODES ENABLED:\n";
-    if (_problem_ptr->legacyUoAuxComputation())
-      oss << "  Computing EXEC_RESIDUAL AuxKernel types when any UserObject type is executed.\n";
-    if (_problem_ptr->legacyUoInitialization())
-      oss << "  Computing all UserObjects during initial setup.\n";
-  }
-
-  oss << std::left << '\n'
-      << "Parallelism:\n"
-      << std::setw(_field_width) << "  Num Processors: " << static_cast<std::size_t>(n_processors()) << '\n'
-      << std::setw(_field_width) << "  Num Threads: " << static_cast<std::size_t>(n_threads()) << '\n'
-      << '\n';
-
   MooseMesh & moose_mesh = _problem_ptr->mesh();
   MeshBase & mesh = moose_mesh.getMesh();
   oss << "Mesh: " << '\n'

It will make my screen output much cleaner and logically making sense.

Thanks.

[permcody]

You could just push a branch with these changes. That makes it easier for everyone to read.

[YaqiWang]

Done. You can check out my branch 'console_info'.

[permcody]

Is problem_ptr defined at the point when Console is constructed?

I think a better solution to this would be to print your output to a buffer and read it back later rather than trying to force the framework to print earlier. I doubt all of the information is available when you want it. Ideally you could print to the _console itself and it should come out after the system information.

[YaqiWang]

I was not careful on this. I think the legacy flags can be checked through _app. All of these info are belonging to _app and should have been available at the right beginning. Logically, these information should come out right after they are available. Making me buffer my stuff will be unnecessary and painful.

[permcody]

Ok legacy flags can be checked but what about the remaining pieces of the header?

[YaqiWang]

SysInfo only has version number, time. Legacy flag is set. Parallelism is determined by the command line. Nothing else need to be outputted earlier. The best way in my opinion is that whenever something is constructed, it outputs its own information right away, like the mesh, systems, and etc. But those are not important to me.

[permcody]

Actually we've been moving away from this pattern in general. In MOOSE we'd like objects to simply initialize themselves at startup. Almost everything else should be done in a separate initialization routine. Most objects have an initialSetup() method that is called to handle this. The reason is that it gives us more flexibility to refactor the framework over time. If objects do a lot of things when they are built including looking around for other objects we find ourselves locked into a very specific initialization order which is not always possible or desirable.

I really would prefer to solve this particular problem a different way. Could your needs be met through a different initialization callback? You're just talking about Actions right? We could probably support that, most other objects have a an init method.

[YaqiWang]

We can name the method in Action as endReport() to give action a chance to summarize what it has done. But I still think information belonging to _app like the version number should be outputted earlier.

[permcody]

So we know that not all of the information can come out early. Some can, some can't. So do we split the information or print it altogether? We chose the latter. I like the idea of giving you a hook to add to the report, even adding to a specific location in the report if you wish. I'll take a look at doing something along those lines if you don't get to it first.

[YaqiWang]

I will let you do it. Not in hurry.

[aeslaughter]

Somehow I missed this entire conversation. But, all of the system information stuff is produced in the Console::outputSystemInformation method. With a few minor tweaks to Console you can create your own Console object (e.g., YakConsole) that can add to this information.

The only catch is that you will not be able to add to this information before the YakConsole object is constructed unless, as mentioned, we come up with a buffering system for the system information you want to add, which isn't too unreasonable.

[permcody]

@aeslaughter - Let's use this ticket per our discussion to output the application header information early.

I propose that we add a call to FEProblem::initialSetup() to output header information at the very top after all the Actions have been executed but before any initial setup is done to the simulation. We'll then call the normal output at the bottom of FEProblem::initialSetup() for the remaining output. That should help with this ticket as well as some of the Multiapp output ordering issues.

[YaqiWang]

Are we having this header capability now? This seems to me a really low hanging fruit.

[aeslaughter]

Yes the header capability is in place, there is a virtual method "header" in MooseApp.

On Tue, Aug 11, 2015 at 11:13 PM, Yaqi notifications@github.com wrote:

Are we having this header capability now? This seems to me a really low hanging fruit.

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/4454#issuecomment-130167913.

[YaqiWang]

I tried, but the header comes out after outputs to _console in action, which is not what we meant to do. See the first few lines in FEProblem::initialSetup().

[aeslaughter]

Can you send me an input file that demonstrates the behavior? I will see what I can do to get things in the correct order.

On Wed, Aug 12, 2015 at 2:56 PM, Yaqi notifications@github.com wrote:

I tried, but the header comes out after outputs to _console in action, which is not what we meant to do. See the first few lines in FEProblem::initialSetup().

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/4454#issuecomment-130445274.

[YaqiWang]

You can checkout my branch header_ordering, and then run yak/tests/actions/diffusion_cfem/diff_cfem.i. The top ci in this branch is the change you want to look at.