Blocks "lost" when switching between apps
Modeling and Simulation made NiCE!
Brought to you by:
amccaskey,
jayjaybillings
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):
simple_ncloop_relap.i
.
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).
Okay, I think the problem is with the way we update the
TreeComposite
based on the new app. Basically, the sameTreeComposite
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.
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.
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.
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.
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.