Menu

#13 Copying parameters from one block to another

1.0
open
None
1
2014-12-10
2014-11-07
No

Look into ways a parameter could be copied from one block to another.

Or, as an alternative, set up some sort of validation when adding a new blank parameter that reminds the user what remaining valid parameters can be added to the block (based on the YAML spec).

Related

MOOSE Feature Requests: #13

Discussion

  • Anna Wojtowicz

    Anna Wojtowicz - 2014-12-05

    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.

     
    • Jordan Deyton

      Jordan Deyton - 2014-12-08

      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.

       
  • Anna Wojtowicz

    Anna Wojtowicz - 2014-12-05
    • assigned_to: Jordan Deyton
     
    • Jay Jay Billings

      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:

      • assigned_to: Jordan Deyton
      • Comment:

      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.


      Status: open
      Milestone: 1.0
      Created: Fri Nov 07, 2014 12:29 AM UTC by Anna Wojtowicz
      Last Updated: Fri Nov 07, 2014 12:29 AM UTC
      Owner: Jordan Deyton

      Look into ways a parameter could be copied from one block to another.

      Or, as an alternative, set up some sort of validation when adding a new
      blank parameter that reminds the user what remaining valid parameters can
      be added to the block (based on the YAML spec).


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/niceproject/moosefeatures/13/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       

      Related

      MOOSE Feature Requests: #13

  • Alex McCaskey

    Alex McCaskey - 2014-12-08

    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.

     
    • Jay Jay Billings

      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:

      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.


      Status: open
      Milestone: 1.0
      Created: Fri Nov 07, 2014 12:29 AM UTC by Anna Wojtowicz
      Last Updated: Fri Dec 05, 2014 08:38 PM UTC
      Owner: Jordan Deyton

      Look into ways a parameter could be copied from one block to another.

      Or, as an alternative, set up some sort of validation when adding a new
      blank parameter that reminds the user what remaining valid parameters can
      be added to the block (based on the YAML spec).


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/niceproject/moosefeatures/13/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Jay Jay Billings
      Oak Ridge National Laboratory
      Twitter Handle: @jayjaybillings

       

      Related

      MOOSE Feature Requests: #13

  • Alex McCaskey

    Alex McCaskey - 2014-12-08

    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.

     
    • Anna Wojtowicz

      Anna Wojtowicz - 2014-12-08

      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.

       
      • Jay Jay Billings

        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:

        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.


        Status: open
        Milestone: 1.0
        Created: Fri Nov 07, 2014 12:29 AM UTC by Anna Wojtowicz
        Last Updated: Mon Dec 08, 2014 03:03 PM UTC
        Owner: Jordan Deyton

        Look into ways a parameter could be copied from one block to another.

        Or, as an alternative, set up some sort of validation when adding a new
        blank parameter that reminds the user what remaining valid parameters can
        be added to the block (based on the YAML spec).


        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/niceproject/moosefeatures/13/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

        --
        Jay Jay Billings
        Oak Ridge National Laboratory
        Twitter Handle: @jayjaybillings

         

        Related

        MOOSE Feature Requests: #13

        • Anna Wojtowicz

          Anna Wojtowicz - 2014-12-08

          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.

           
          • Jay Jay Billings

            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:

            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.


            Status: open
            Milestone: 1.0
            Created: Fri Nov 07, 2014 12:29 AM UTC by Anna Wojtowicz
            Last Updated: Mon Dec 08, 2014 03:03 PM UTC
            Owner: Jordan Deyton

            Look into ways a parameter could be copied from one block to another.

            Or, as an alternative, set up some sort of validation when adding a new
            blank parameter that reminds the user what remaining valid parameters can
            be added to the block (based on the YAML spec).


            Sent from sourceforge.net because you indicated interest in
            https://sourceforge.net/p/niceproject/moosefeatures/13/

            To unsubscribe from further messages, please visit
            https://sourceforge.net/auth/subscriptions/

            --
            Jay Jay Billings
            Oak Ridge National Laboratory
            Twitter Handle: @jayjaybillings

             

            Related

            MOOSE Feature Requests: #13

  • Jordan Deyton

    Jordan Deyton - 2014-12-08

    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...

     
    • Anna Wojtowicz

      Anna Wojtowicz - 2014-12-08

      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?

       
      • Jordan Deyton

        Jordan Deyton - 2014-12-08

        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.

         
        • Jay Jay Billings

          That's by design. It's called REST.

          Jay
          On Dec 8, 2014 11:03 AM, "Jordan Deyton" jdeyton@users.sf.net wrote:

          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.


          Status: open
          Milestone: 1.0
          Created: Fri Nov 07, 2014 12:29 AM UTC by Anna Wojtowicz
          Last Updated: Mon Dec 08, 2014 03:50 PM UTC
          Owner: Jordan Deyton

          Look into ways a parameter could be copied from one block to another.

          Or, as an alternative, set up some sort of validation when adding a new
          blank parameter that reminds the user what remaining valid parameters can
          be added to the block (based on the YAML spec).


          Sent from sourceforge.net because you indicated interest in
          https://sourceforge.net/p/niceproject/moosefeatures/13/

          To unsubscribe from further messages, please visit
          https://sourceforge.net/auth/subscriptions/

           

          Related

          MOOSE Feature Requests: #13

  • Anna Wojtowicz

    Anna Wojtowicz - 2014-12-10

    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.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.