search

idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.76k stars 1.05k forks source link

Verbose output from Executioner #3202

Closed bwspenc closed 10 years ago

bwspenc commented 10 years ago

The "verbose" parameter in the executioner turns on lots of detailed information from the executioner and timestepper. That used to enable the printing out of the old time, but it looks like that piece of it got moved over to the Console output block. Now a user has to know to put "verbose" in both the Executioner block and the Console block. Any way we could control verbose output related to the Executioner in just one place (preferably in the Executioner block since that's what the verbose output is related to)?

permcody commented 10 years ago

I would vote for one place, but have that one place in the Outputs block.

Sent from my iPhone

On May 23, 2014, at 6:12 AM, Ben Spencer notifications@github.com wrote:

The "verbose" parameter in the executioner turns on lots of detailed information from the executioner and timestepper. That used to enable the printing out of the old time, but it looks like that piece of it got moved over to the Console output block. Now a user has to know to put "verbose" in both the Executioner block and the Console block. Any way we could control verbose output related to the Executioner in just one place (preferably in the Executioner block since that's what the verbose output is related to)?

— Reply to this email directly or view it on GitHubhttps://github.com/idaholab/moose/issues/3202 .

YaqiWang commented 10 years ago

Or we allow AddExecutionerAction to modify parameters of AddOutputAction. For example, we compare the verbose value in Executioner block and Outputs block and set the maximum one.

permcody commented 10 years ago

@YaqiWang From a framework standpoint, I'm not crazy about ideas like this. They feel hackish... too many knobs for something that should be easy. Let's just pick one consistent way and do it.

aeslaughter commented 10 years ago

I think for now the Console object could check the Executioner, if the Executioner has it turned on, then turn it on in the Console. However, this opens up a large conversation of how users should do there own output, specifically to the Console, see #2571. (I started working on some of this last week: https://github.com/aeslaughter/moose/tree/messages-2571)

Personally, I would like to see all output handled via the [Outputs] block as I would like to see one place in your input file to control behavior rather than setting a flag in each one of your custom Kernel, or IC, or AuxKernel, etc. I have hopes that users start to make their own output objects to do whatever complicated output they need, allowing them to control various aspects from one central location.

YaqiWang commented 10 years ago

I think we need a small write-up for executioner developers on using output system. Especially when we developing the executioner, we want to create some screen/file outputs for debugging purpose. Using Steady, Transient and EigenExecutionerBase as examples for this write-up will be great. For example if outputs in Moose::out always go to Console and controlled by its Verbose. Verbose can be an integer instead of bool for better controlling the level of verbose. It will be nice that these kinds of things can be documented.

Another issue created by @bwspenc on the other hand is different though. sync_times logically should be for the executioner. We want to solve at these particular times due to the singularity of the physics. I do not think it is proper to move this parameter into outputs.

friedmud commented 10 years ago

@YaqiWang as for sync_times it was originally intended to force output at certain times... not just to solve at those times (although that is a consequence). It is an output feature (albeit, one that is tied to closely to execution).

friedmud commented 10 years ago

@aeslaughter I agree that I would like to see all "console" related output flow through the Console object.... how to do that reliably I don't yet know.

Let's talk about this after @permcody and I get back