#31 Blocks "lost" when switching between apps

[Jordan Deyton]

I've managed to "lose" blocks when switching between available MOOSE apps.

To reproduce this, I used the following steps (although it appears to be a problem with any app):

1. Import a MOOSE input file, e.g., simple_ncloop_relap.i.
2. Switch the app to relap.
   • Note that the block EoS has parameters/sub-blocks.
3. Switch the app to bison.
4. Switch the app back to relap.
   • Note that the block EoS is now empty.

[Jordan Deyton]

Also, there may be a problem with either the relap syntax/yaml files or the relap input files. The input file above has a block "Output" that disappears when selecting the relap app. The relap tree instead has a block "Outputs" (with an s).

[Jordan Deyton]

Okay, I think the problem is with the way we update the TreeComposite based on the new app. Basically, the same TreeComposite gets converted to different MOOSE apps and loses information along the way.

For instance, "EoS" is in the relap tree but not the bison tree, so the conversion from relap to bison eliminates it from the TreeComposite. The conversion back to relap then is based on this modified tree, so the resulting relap-based tree is also missing "EoS".

Frankly, I'm not sure how the MOOSE team would want to handle this situation. On the one hand, we could reload the file from scratch each time the app is switched, but then you would lose any unsaved changes to the input. On the other hand, if we continue as is, we lose unsupported blocks.

[Jordan Deyton]

Setting the priority to 7 and the owner to Anna for now. We may need further input from the MOOSE team before making any changes based on this ticket.

[Anna Wojtowicz]

This is how it is intended to work to people can't invent their own blocks that the MOOSE codes won't recognize, but it has the side effect you mentioned. In reviewEntries(), it compares the TreeComposite to the YAML file and any blocks that are not matched are discarded. I don't know if there's anything we can/should do about it.

The Output vs. Outputs blocks is something we used to allow an exception for, but we've since removed it. This is a discrepancy between old (Output) vs. new conventions (Outputs), and the result of using an outdated input file. The real question is if it's our responsibility to juggle these kinds of legacy artifacts.

[Jordan Deyton]

It might be better to, instead of silently removing it from the tree, mark the block as invalid and prohibit exporting the invalid tree to an input file.

[Jordan Deyton]

I think this might be something worth bringing up with the MOOSE folks. It seems like this feature can be bad for someone who accidentally clicks the wrong item in the MOOSE app dropdown.

I'll set it to pending for now.