3 Replies Latest reply on Jun 20, 2018 3:11 PM by lmalone

    AF Element Rename Doesn't Affect Formula??



      I want to trace a series of formulas so that I can see a high-level dependency between various elements and subsequent formulas.

      In essence I would like to determine which inputs to a model affect which outputs, so I can create a dependency matrix.

      At present my thinking is:

      1. Rename the "Input" Element
      2. Look for all "Result" formulas that have error (that are therefore dependent, directly or indirectly, on the "Input")
      3. Name the "Input" back


      However - there must be some caching or something going on, as when I rename the Input I do NOT see any errors in a dependent formula unless I go into the formula, and manually "Evaluate".

      What can I do to have AF recognize the new Element name (and throw the errors I am expecting) as soon as it is renamed??  Or are there any better ways to trace high-level dependency??




        • Re: AF Element Rename Doesn't Affect Formula??

          Hi Stuart,

          you can use String Builder attributes in same Element to retrieve attributes from other locations with substitution syntax.

          Then refer these attributes to the formula.



          Attribute Test from upper element...

          I create attribute "Test attribute" with reference ..\|TEST


          After that, refer these attributes to the formula...

          In this case, if you change element name formula continues to be calculated.



            • Re: AF Element Rename Doesn't Affect Formula??

              Thanks for taking the time to respond, Igor, but I think maybe I didn't pose the question correctly!?!


              I want the element name to be manually updated (to be incorrect !), so that I can force an error and therefore trace all calculations dependent on that (original) element through their error status.

              So, if my calculations are dependent on "Input1", and I manually change the name to "Input1a", I expect everywhere that referenced "Input1" will now NOT be able to find it, and generate an error accordingly (and therefore further dependent calculations would also be in error).

              But when I change the element name, none of the formulas update with an error unless I manually force it by going into the formula.  So while the formula is still referencing "Input1" (which now doesn't exist), I suspect it's pointing to "Input1a" through a cache, reference or other mechanism, and doesn't recognize the element name has changed.  Unless I make it recognize through a manual formula "evaluate".


              So what I want to know is, is there a way to have all formulas re-parse the element names so that my "bad" name is recognized such that it then propagates errors??

              (As an alternative, I am introducing a calculation error on the element value, and this propagates errors as I expect - so not a deal breaker.  But this is not the first time I've changed element names and not had them recognized as changed in formulas, such as when I am developing a model that re-uses similar formula.)


              Thanks anyway!


                • Re: AF Element Rename Doesn't Affect Formula??

                  Hi Stuart,


                  I did some testing and was able to get this working. I think you're correct, there is some caching in the AF SDK. To workaround this, you can simply close and re-open PSE after checking in the rename; then the dependent outputs should display an error.


                  Update: The only thing I can think of to find dependencies among attributes is by leveraging the AFDataReference.GetInputs() AFSDK method.


                  Here is a simple script that outputs the full path of all input attributes to my attribute named 'Formula':


                  var afdb = new PISystems()["myPISystemName"].Databases["QA 2"];
                  var attr = afdb.Elements["Element1"].Attributes["Formula"];
                  var inpts = attr.DataReference.GetInputs(null);
                  Parallel.ForEach(inpts, i =>