Best Practices for Optimal Performance in ArcFM - Feeder Manager 2.0

Version 20

    This document describes the following best practices:



    Finding de-energized features, loops, and multi-feeds

    • Symbology

      The user-centered architecture of feeder information in Feeder Manager 2.0 offers easy symbology mapping to visually highlight de-energized features, multi-feeds, and loops. Tie symbology to the Loop field to highlight loops and use the Number of Feeders field to visually locate de-energized and multi-feed features.

      Best Practice: Do not leave your symbology layers on. Instead, enable the layers only when your workflow requires them. Having your loop symbology layer on while making edits will slow your processes, so wait to enable the layer until you're actually interested in finding loops.

    • Definition Queries

      In general, the use of definition queries on Feeder Manager 2.0 fields is not advised. The reason for this is that specific queries cause a full network trace to come up with the result and the performance of some tools can be negatively impacted.  Symbolizing on FM2.0 fields can be used for most use cases and is the recommended approach with FM2.0 as it will only trace the current map extent.

      Best Practice: As with symbology, normally have definition query layers turned off (disabled) and ONLY enable once you need the query's results.

      Best Practice: Feeder Manager 2.0 is fast because it does not store data. As a result, Feeder Manager 2.0 must perform a trace to answer queries. With this in mind, you will want to build specific queries that will trace only the map extent instead of general ones that will force a full table scan and trace of your entire network. In general, just querying your map extent is a more efficient approach.

    • Export by Feeder tool

      The Export by Feeder geoprocessing tool is provided with Feeder Manager 2.0. The tool traces the feeders you specify and appends the Feeder Manager 2.0 feeder information to the individual features. It also exports all of the other attributes on a feature.

    • Public APIs

      Custom applications can query feeder information from Feeder Manager 2.0.



    Avoid unnecessary tracing


    When it involves features that don't currently belong to your Feeder Manager 2.0 cache, network tracing can take a noticeable amount of time. The amount of time it takes depends on the number of feeders traced—more feeders require more time. To improve performance, you can easily avoid many operations that query the database and cause Feeder Manager 2.0 to trace your network. Employ each of the following practices for a much more efficient experience.


    Put symbology to work

    Symbology inspects only the data belonging to the extent. Use this to your advantage! Spend some time considering the levels at which you need to see things in your map.


    At large map scales, you should avoid basing your symbology on Feeder Manager 2.0 fields.


    Limit your use of Select By Attributes

    If your query includes Feeder Manager 2.0 plug-in fields, this tool scans the entire database for attributes defined in your query.


    Again, consider setting up symbology instead. For example, create a new group layer that you can use to symbolize looped, multifed, or de-energized areas of your network.


    And don't forget about the Find Feeder tool's Zoom to Extent command.


    Stop opening attribute tables via right-click

    When you open the attribute table on a layer in this fashion, ArcMap returns the first 2000 features it finds. This usually incurs an unnecessary and time-consuming amount of network tracing:


    There's a much more efficient way to do this that doesn't require unnecessary tracing. First, use the Find Feeder tool to select all of the features belonging to a feeder:


    Then List By Selection:


    Now you can open a table of the selected features:


    If you're not interested in Feeder Manager 2.0 data, you can disable the automatic joins, as described in the section below. Doing so restores the performance of the Open Attribute Table command. You can extend this practice by, for example, creating a group layer for the purpose of locating features with attributes that don't include Feeder Manager 2.0 data.

    Save new stored displays for users who don't care about feeder information

    If you have users who don't care about feeder data, there's no sense in expending any computational effort on providing such data. In those cases, when your data are configured for Feeder Manager 2.0, design stored displays that won't automatically join their layers to the plug-in data. Simply uncheck a layer's Join FM2.0 Feeder Info Fields option. Save the stored display with a new name and you're done.


    Don't return Feeder Manager 2.0 information in the Locator

    Feeder tracing operations are required when locating features that participate in a network configured for Feeder Manager 2.0. Unchecking this option improves performance:


    Additionally, don't use the ArcFM Locator to search based on feeder information fields. Instead, use the Find Feeder tool, which was designed expressly for that purpose.


    Note that the Locator displays whatever feeder data currently reside in the Feeder Manager 2.0 cache. If the cache is currently populated with feeder data relevant to the Locate operation you're conducting, you will see data in the Feeder Manager 2.0 fields even when the option to Return FM2.0 Data is turned off.


    Use basemap layers to improve draw times


    Because edits that affect the Feeder Manager 2.0 cache cause a refresh of the geography draw phase, we recommend that you take advantage of basemap layers in your stored displays. If you move feature layers you're not editing into a basemap layer, you can take that data out of the map's geography cache, thereby improving draw times while editing.


    Clean your local storage


    At the 10.2.1a release there is a configuration option to cleanup local storage files automatically. At 10.2.1, this needs to be done manually or via a script. Because Feeder Manager 2.0 generates an .edb file for each session and version, these files may occupy more space than you'd like. Deleting them in no way damages your data or has any deleterious consequences. You can find them here:


    \Users\user\AppData\Roaming\Miner and Miner

    The .edb files will look similar to this:



    Use feeder change events sensibly with your customizations


    Keep in mind that the performance advantage of Feeder Manager 2.0 is that it minimizes database-write operations. Customizations that use these events extensively will degrade the performance of Feeder Manager 2.0. For example, using the events to update the label text field on conductors could be costly because of the large number of features that might need updating. Check the Resource Center to find out more about the feeder change event.


    Use Feeder Manager 2.0 layer order to maximize efficiency


    Beginning with 10.2.1b, you can order the read-only Feeder Manager 2.0 fields similar to the way you can order the list hierarchy of other feature fields. You can place the group of fields at the beginning of the feature field list, the end, or after a specific field you select. The optimum spot will depend on your workflow, but the goal will be to limit the scrolling that your analysts will need to perform to view feeder information for a feature. You can learn more about the field order feature on the Resource Center.