Copying parameters from one block to another
Modeling and Simulation made NiCE!
Brought to you by:
amccaskey,
jayjaybillings
Tagging Jordan so he sees this.
In the Property View when you try to add a parameter, would it be feasible to have some sort of pop-up list of parameters that can be added to a block in the same way you get a pop-up list of children that can be added in the TreeView?
This would require storing the list of possible parameters on the TreeComposite the same way that it stores a ChildExemplar list -- I'm not sure if this would seriously bog down a TreeComposite with too much data or not. The benefit though, would be to both address this ticket, and also to allow users to be able to add parameters that are supposed to have a discrete set of values.
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.
What if I wanted a parameter that wasn't in the list?
On Dec 5, 2014 3:38 PM, "Anna Wojtowicz" awoj@users.sf.net wrote:
Related
MOOSE Feature Requests: #13
Presumably for a discrete parameter, adding a parameter that is not in the list would/should not be allowed by the YAML. The YAML would specify the discrete parameter list as a MooseEnum, thus limiting what the user can choose and what we should show. If the Moose dev wanted to add a parameter to the list they'd have to modify the YAML generation in their MooseApp.
As we have learned, the YAML spec is more of a guideline. They have
specifically asked in the past for the ability to add parameters that are
not in the YAML file.
On Mon, Dec 8, 2014 at 8:30 AM, Alex McCaskey amccaskey@users.sf.net
wrote:
--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
Related
MOOSE Feature Requests: #13
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.
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.
Yes, whenever you add something that didn't come from the YAML it will
always be AllowedValueType.Undefined. That's the functionality that we need
to preserve because they want it for testing.
On Mon, Dec 8, 2014 at 10:26 AM, Anna Wojtowicz awoj@users.sf.net wrote:
--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
Related
MOOSE Feature Requests: #13
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.Yeah, I got all of that. Go forth and codify!
On Mon, Dec 8, 2014 at 10:41 AM, Anna Wojtowicz awoj@users.sf.net wrote:
--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
Related
MOOSE Feature Requests: #13
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...
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?
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.
That's by design. It's called REST.
Jay
On Dec 8, 2014 11:03 AM, "Jordan Deyton" jdeyton@users.sf.net wrote:
Related
MOOSE Feature Requests: #13
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.