Recent changes to moosefeatures

#13 Copying parameters from one block to another

Anna Wojtowicz — Wed, 10 Dec 2014 17:43:15 -0000

The MOOSEModel form now exposes the YAML tree at the component with id=3, although I don't think there's anyway we can actually expose the HashMap that indexes it.

#6 Post processing visualization

Anna Wojtowicz — Tue, 09 Dec 2014 19:21:02 -0000

status: open --> closed

#11 Some MOOSE block parameters need discrete set of values

Anna Wojtowicz — Tue, 09 Dec 2014 19:17:46 -0000

status: open --> closed

#13 Copying parameters from one block to another

Jordan Deyton — Mon, 08 Dec 2014 16:03:07 -0000

Well, the UI can access the Form created by the MOOSEModel. There's not an easy way to access the MOOSEModel directly as far as I can tell.

#13 Copying parameters from one block to another

Anna Wojtowicz — Mon, 08 Dec 2014 15:55:28 -0000

The MOOSEModel does at one point construct a HashMap of the whole exemplar tree at one point, although it's discarded when its method goes out of scope. I could just store the HashMap on the MOOSEModel though -- would the UI be able to access it from there?

#13 Copying parameters from one block to another

Jordan Deyton — Mon, 08 Dec 2014 15:50:16 -0000

I think the UI side can be done fairly easily. What I'm thinking of doing is replacing the add/remove buttons (and the type selection widget for AdaptiveTreeComposites) with a ToolBar.

However, it sounds like the brunt of the work lies on the data side...

#13 Copying parameters from one block to another

Jordan Deyton — Mon, 08 Dec 2014 15:45:18 -0000

If you are copying lists of strings, it could make the TreeComposite even more heavyweight. On the other hand, it should be okay if you are taking full advantage of Java references and reusing exemplar information when possible.

#13 Copying parameters from one block to another

Anna Wojtowicz — Mon, 08 Dec 2014 15:41:55 -0000

Right, and I'm saying we can keep that, but there's also no way to add a parameter with AllowedValueType.Discrete. That could be fixed by presenting the user with a list of parameters to choose from, which also contains a "blank" parameter in the same way that we have "BlankBlock" on the list of blocks that can be added.

#13 Copying parameters from one block to another

Anna Wojtowicz — Mon, 08 Dec 2014 15:26:12 -0000

The parameter with a discrete list of values is a separate ticket I'm working on right now.

Mostly what I was addressing with this ticket is when you click the "+" button to add a new parameter, pop open a list of all the possible parameters associated to a block. It occurred to me as I work on the discrete parameter value ticket, there's no way to have a parameter that has a discrete set of values, unless it was originally imported. Whenever you add a parameter by clicking the "+" button, it will always have AllowedValueType.Undefined.

A "BlankParameter" can also be added to this hypothetical list to retain the ability to add any parameter they want, even if it's not in the YAML.

#13 Copying parameters from one block to another

Alex McCaskey — Mon, 08 Dec 2014 15:03:14 -0000

I think we may be talking about two different things. Yea I agree, they did mention that they wanted to have the ability to add parameters that are not in the YAML. So we should definitely keep that functionality.

But what I understood Anna's comment to be addressing was the capability to place a discrete Entry (ie a dropdown widget) in the Properties tab for parameters that can only take on a specific set of values. This is something they requested from us when we were there last time, such that they don't have to remember those values / type them in manually, risking a possible typo. I was saying that it would not make sense to allow them to add a parameter to that discrete list. But adding a new parameter to a block is allowed and should remain so.