Enable merged input file support

[dschwen]

Reason

Per idaholab/moosetools#68 (which is now implemented)

I propose to add multiple input file support to MOOSE. This would internalize the (pending) hit merge functionality in MOOSE, so you could run

./moose-opt -i analysis1.i -i common_stuff.i

This way users could factor out common input block and parameters into a separate file. I'm working on an analysis of a transient with 14 distinct phases, that I'm splitting into 14 different inputs that restart off of each other. About half teh content of those inputs is shared and could be factored out into a separate file, making parameter adjustments in teh common parts a 1 file change, rather than a 14 file change. This would also reduce a source of errors, where forgetting to apply a change in one of the files could break restarts (possibly late in the simulation).

An internal merge functionality would give the user meaningful errors, pointing to the lines in the respective inputs! I.e. the user would be made aware of an error in common_stuff.i:24 or analysis.i:134.

Design

Utilize the HIT Node::name() functionality to recover the input filename when generating paramErrors. Rework MooseApp to remove the assumption of a single input file name. Loop over input files and use the hit::merge function to combine them into a single tree.

Impact

Added functionality and convenience.

[dschwen]

The semantics of specifying multiple -i parameters might be unclear to a new user at first. If the user assumes MOOSE will simply run two independent simulations one after another and is supplying two full input files, they will most certainly encounter a parse error. We should output an info message along the lines of

Merging multiple input files {'analysis1.i', 'common_stuff.i'}.

[cticenhour]

I agree that the semantics would end up being confusing in that case, and like the extra output message to clarify. Why can't we have a single -i flag with a list of inputs to make the command itself cleaner (and maybe easier to understand for some users)?

[dschwen]

Our command line parser expects one argument (or zero) after each option. I could enable a -i file1.i file2.i syntax with a small modification. I.e. digesting every argument until I find one that starts with a -. How does that sound?

[dschwen]

Ok, I like that, especially since it was such a small tweak!

[cticenhour]

Oh, easy - I like it!

[rui-hu]

@dschwen This will be a very useful feature. How the restart would look like for the multiple input simulation?

[lefebvrera]

@dschwen I know I'm late here, but is there a reason a file import mechanism wasn't an option? Is it a possible option for the future?

E.g., somewhere in analysis1.i there exists

...
include common_stuff.i
...

The nice thing about file imports is it provides embedded traceability of the entire analysis problem as opposed to traceability only at runtime.

So for our tools that assist with validating the semantics of the problem (NEAMS Workbench, Peacock, etc.), they won't require users and reviewers to provide full context (i.e., all input files) because the input itself describes the entire problem via the parts included.

Also, the include could occur in specific contexts (subblocks, etc.) which can enable additional flexibility in the input. E.g., factor out a common block instruction set and after inclusion in a subblock add context-specific instructions.

E.g.,

...
    [xyz]
        include common_xyz.i
        more = data ...
    []
...

From a review's perspective, the input can be quickly identified and opened via typical IDE interactions (CTRL+Left-click, etc.).

[dschwen]

Yes, there is a reason. I'm on the road right now. Details later

…

On Mon, Aug 9, 2021, 5:37 AM Robert A Lefebvre ***@***.***> wrote: @dschwen <https://github.com/dschwen> I know I'm late here, but is there a reason a file import mechanism wasn't an option? Is it a possible option for the future? E.g., somewhere in analysis1.i there exists ... include common_stuff.i ... The nice thing about file imports is it provides embedded traceability of the entire analysis problem as opposed to traceability only at runtime. So for our tools that assist with validating the semantics of the problem (NEAMS Workbench, Peacock, etc.), they won't require users and reviewers to provide full context (i.e., all input files) because the input itself describes the entire problem via the parts included. Also, the include could occur in specific contexts (subblocks, etc.) which can enable additional flexibility in the input. E.g., factor out a common block instruction set and after inclusion in a subblock add context-specific instructions. E.g., ... [xyz] include common_xyz.i more = data ... [] ... From a review's perspective, the input can be quickly identified and opened via typical IDE interactions (CTRL+Left-click, etc.). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17989 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRMPXUOG5FP5TE5OGB3D3T37DZLANCNFSM457FD75A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[dschwen]

Old school include file support is fairly unsophisticated. You can probably already do that by preprocessing inputs with the C preprocessor. But... Include files are position dependent (it matters where you put the include statement, top or bottom, inside or outside blocks), and Let's say one include file defined part of the executioner block and a second "include" file wants to set the end time parameter in the Executioner block, or you want to override a specific parameter. The include paradigm will fail at both, because you're adding a second top level executioner block (which will trigger the setup executioner action twice) and in the other case you'll be doubly defining parameters (->error). The way multiple inputs are implemented now, merging happens at the AST level, all file sources (file name and line) for every parameter get preserved and all parameter overrides are captured as info messages.