Insider's Guide to Feeder Manager 2.0

Version 6

    What are the main differences between Feeder Manager 1.0 and 2.0?

     

    The original edition of Feeder Manager stores FeederID and related information in feature attributes, in a versioned geodatabase. That strategy carries a notorious cost in terms of (1) editing performance and (2) the frequency and magnitude of version conflicts when users reconcile and post their edited versions.

     

    Feeder Manager 2.0 tracks feeder information in memory. Editing performance of Feeder Manager 2.0 is superior to that of Feeder Manager 1.0, and you can expect fewer and smaller version conflicts. Accessing feeder information outside of ArcMap, however, requires running the Feeder Export or other geoprocessing tools and may require you to update existing customizations.

     

     

    What else changed between Feeder Manager 1.0 and 2.0?

     

    In addition to the points listed in the Using Guide on the ArcFM Resource Center, consider the following details about Feeder Manager 2.0.

     

    Mismatched phases

     

    Any phases of a junction feature that are not present in the feature's PhaseDesignation are not considered as energized by Feeder Manager 2.0. This is in contrast to Feeder Manager 1.0, which considers a junction feature as energized on any phases that reach the junction from a power source, regardless of the junction’s PhaseDesignation (if a junction feature class does not have a PhaseDesignation field, e.g., the default junction class, then it will be considered energized on whatever phases reach it).

     

    Missing phase designation data

     

    Missing phase designation data impedes Feeder Manager 2.0’s tracing performance. When phase designation values are null, Feeder Manager 2.0 requires more time to filter energized phases.

     

    Non-traceable junctions

     

    Feeder Manager 2.0 recognizes the FDRMGRNONTRACEABLE model name for both junctions and edges. This is in contrast to Feeder Manager 1.0, which only pays attention to the FDRMGRNONTRACEABLE model name for edge features, and not for junctions.

     

    Tie Devices

     

    In order for Feeder Manager 2.0 to recognize a feature as a tie device, the feature must meet all of the following criteria:

     

    1. The feature must be an open, switchable device. For example, dynamic protective devices can be tie devices. Service points and transformers cannot. Any switchable device can be a tie device.
    2. The device can be reached by sources or subsources from both directions (say left and right) on at least one phase, where at least one of the sources reaching it on the left does not also reach it on the right, and vice versa. Subsources that reach the device must have the same feeder level in order to qualify for consideration.
    3. When you close the device, at least one adjacent conductor that was already energized on at least one phase, will become energized on that same phase by a new source or subsource, i.e., by a source that could not reach that phase of the conductor while the device was open.

               

    With the exception of the new Multifeed Feature validation rule, Feeder Manager 2.0 considers all tie devices to be “multi-fed,” in the sense that the FeederIDs field of a tie device lists all of the sources that energize the device. Note that subsources feed, but do not energize, downstream features. Subsources themselves must be energized in order for the Find Feeder tool to discover them.

     

     

    How do I know if Feeder Manager 2.0 is performing properly?


    This section shows some performance numbers and test scenarios that you can use as a guide to determine whether something is wrong with your Feeder Manager 2.0 configuration or data.


    The following data come from tests performed on a machine with an Intel® Core™ i7-2600 CPU @ 3.40GHz, a 64-bit operating system, 16 GB of RAM, and used a personal SDE database containing GRU data.

     

    Test 1: Time required to build the cache by selecting all service points within a particular extent (no symbology driven by plug-in fields)

     

    Number of features in bookmark’s extentNumber of features tracedBenchmark (s)
    10014,658<1
    58,000116,52611
    138,000257,51425
    260,000317,92549

     

    Test 2: Time required to build the cache with symbology driven by plug-in fields

     

    Number of features in bookmark’s extentNumber of features tracedBenchmark (s)
    10014,658<1
    58,000116,5269
    138,000257,51416
    260,000317,92523

       

    Test 3: Time required to export one feeder and all feeders with the Export By Feeder geoprocessing tool


    FeederTotal featuresBenchmark
    Feeder 5427,12125s
    All feeders317,92515m 58s

     

     

    In what ways can I ensure optimum performance?

     

    First, refer to Best Practices for Optimal Performance in ArcFM - Feeder Manager 2.0.

     

    Performance Considerations of the Feeder Change Event

     

    Feeder change events allow your customizations to react to changes in an edit session that affect feeder information for a given feature. If you attempt to update a lot of features at once using these events, you will find performance suffers. For example, using events to update the label text field on conductors could become costly rather quickly because of the large number of affected features. You should consider performance whenever creating customizations that leverage the feeder change event. If you do not have a customization listening for feeder changes, Feeder Manager 2.0 does not emit them to ensure optimum performance.    

     

    Feeder Manager 2.0 Field Order

     

    By design, Feeder Manager 2.0 fields do not exist on feature classes so you cannot individually order them in the same way as feature class fields. You can, however, determine where the group of Fedder Manager 2.0 fields (including custom fields) appear in the list of an electric geometric network feature's attributes. Use the ArcFM Properties Manager to place the read-only fields at the top of the list, the bottom, or beneath any other field that makes the most sense for your implementation. 

     

    Map Layers


    You should configure map layers with symbology or labels driven by plug-in fields to draw only at map scales that include a few thousand features, not more. Stick to good map design principles. Don’t use feeder-driven symbology at all scales. Expect performance problems if you do.

     

    Microsoft Esent Settings


    Microsoft Esent supports the local storage mechanism of Feeder Manager 2.0. The ArcFM installer adds a single .dll to enable Esent support for Feeder Manager 2.0. Esent itself is included in every Microsoft Windows installation (since Vista).


    Feeder Manager 2.0 uses these locally stored Microsoft Esent databases to mimic the Feeder Manager 2.0 cache and relies upon them in the event that the cache becomes too large. Like the cache, the local Esent databases store tracing-derived information, including Feeder IDs and Feeder Info.

     

    Additionally, the data is stored locally per version. When a version is changed, a new database is created for the version. The existing database remains and can be re-used if you switch back to the version to which it refers. When you close ArcMap, the local database files remain.


    When using SDE, Feeder Manager 2.0 checks the existing Esent database and reuses it if its data are still valid. If not, it rebuilds the Esent store every time you open a new session or reconnect. For file and personal geodatabases, the Esent store is rebuilt at the start of every session.
    The Esent databases reside in the user's AppData\Roaming directory.


    Feeder Manager 2.0 is optimized out-of-the-box for the majority of use cases. There are a variety of registry key values, however, that you can use to adjust the way Esent works with Feeder Manager 2.0. There are only three reasons that should make you consider using these values to improve performance:

    1. You have a very small network.
    2. You have a large electric network with more than 1500 circuit sources or so.
    3. You have a very good reason for tightly limiting memory consumption, such as a Citrix environment.


    These values must be created in HKEY_CURRENT_USER\Software\Miner and Miner\ArcFM8\Feeder Manager:

     

    • EsentDisabled: Create this DWORD value and set it to 1 to turn off Esent. This eliminates local storage of Feeder Manager 2.0 data. You should only consider using this option to increase performance if you have a very small network.

     

    • EsentMaxCacheSizeBytes: Create this DWORD value to specify the maximum amount of memory you'll allow Esent to use, in bytes. By default, Esent uses a maximum of 200 MB (209715200). Note that this affects the size of the Esent database only—not the process. ArcMap is larger, and so is any client application that uses the Feeder Manager 2.0 public API.

     

    • FeatureThreshold: Create this DWORD value to specify how many features are stored in Esent's memory cache before writing to the Esent database. This alters the point at which Esent starts its work. The default is 50,000 features. Only lower this value if you must strictly limit the amount of memory consumed by ArcMap, and you can tolerate the resulting performance impact. Only raise this value if you're attempting to improve Feeder Manager 2.0 performance on a very large network with more than 1500 circuit sources, and you can tolerate ArcMap's resulting memory consumption.

     

    • NetworkCapacity: Under very rare circumstances it’s possible to encounter an out-of-memory exception. You can try lowering this DWORD value to address such exceptions. This value controls the size of the internal cache of the geometric network (not the feeder info cache). The default value is 800000, which means that the network cache can hold up to 800,000 junctions, 800,000 edges, and 800,000 adjacencies at a time. Like the UnleashEsent value described below, this number controls only part of the memory used by the process.

     

    • UnleashEsent: Create this DWORD value and set it to 1 (true) if you want Esent to use as much memory as it wants. Set it to 0 (false) in order to respect the EsentMaxCacheSizeBytes value (described above). By default, Esent respects the EsentMaxCacheSizeBytes value. Or, if you create neither the UnleashEsent nor EsentMaxCacheSizeBytes values, Esent uses a maximum of 200 MB of memory. Use the following guidelines to determine whether and how to use this value:
      • Available RAM on the client machine or within the citrix session:  Most desktop machines have plenty of available RAM, in which case it makes sense to use the UnleashEsent value. For those who use Citrix server, however, the decision to use the UnleashEsent value should depend on the resources available to a Citrix session. It’s probably safe to unleash Esent if 4GB are available. Although the single 32-bit process in Citrix environments cannot use all of that, users probably need some of that 4GB for other applications.
      • The number of SOCs in a server environment: UnleashEsent tells Esent to use as much memory as it likes. In a desktop environment that can only be around 2GB because it's a single 32-bit process. In a server environment, however, it's a 64-bit process that could easily consume a substantial portion of available memory. Multiply that by the number of services that host layers with joined FeederInfo data on each ArcGIS Server host machine. We therefore recommend creating the UnleashEsent value on Server, but setting it to 0 so that it respects the EsentMaxCacheSizeBytes value. Then decide how much RAM to give Feeder Manager 2.0 on each SOC, and set the EsentMaxCacheSizeBytes to that value.

     

    Citrix users must bear in mind that these settings are unique to the session and user. Make sure you don't exhaust your Citrix server's resources by, for example, unleashing Esent for all users.


    Personal and file geodatabase users may notice a new file with the .fm extension stored in the location containing your PGDB or FGDB. Feeder Manager 2.0 creates such files so that Esent can track when database changes occur.


    Note that there’s currently a bug (MM51934) in Feeder Manager 2.0 with respect to Esent. When the default Esent database is locked, it always creates a new database rather than checking for another unlocked database. The result of this issue is that, over time, you may find Esent databases consuming an unnecessarily large amount of disk space. ArcFM never deletes stale databases. The workaround is to delete older files manually.

     

     

    Will Feeder Manager 2.0 work with my customizations and autoupdaters that rely on FeederID? What can I do to fix them?

     

    Existing customizations on ArcFM Solution 10.2.1b and newer

     

    We added a feeder change event to the API for ArcFM 10.2.1b. You can listen for these events to fire your autoupdaters when feeder information changes. See the Feeder Change Event topic in the Customization Guide on the ArcFM Solution Resource Center for more details.

     

    Existing customizations on ArcFM Solution 10.2.1a and older


    Any custom autoupdaters that respond to a change in FeederID value for a feature class do not work with Feeder Manager 2.0 (assuming you have turned off Feeder Manager 1.0). This is because Feeder Manager 2.0 does not update the FeederID field of the features. Further, changes that occur in Feeder Manager 2.0’s joined plug-in tables cannot trigger autoupdaters.

     

    Approaches to replace or work around broken customizations for versions of ArcFM Solution prior to 10.2.1b

     

    Custom Plug-in Fields

     

    You may find that creating custom feeder fields allows you to achieve the same purpose as the custom autoupdaters that respond to changes in FeederID or FeederInfo. Visit the developer samples for more guidance. There are two of them. The first is a class module that provides a replacement field for fields that currently rely on feeder information changes. It demonstrates how to concatenate feature values with Feeder ID. The second is a class module that provides the first Feeder ID of a feature.


    Pay special attention to the instructions under the How to Implement heading.

     

    Public API

     

    If you have a feature from a geometric network that has been configured for Feeder Manager 2.0, you can call a method belonging to the FeederInfoProvider class to retrieve the FeederID and other tracing-derived information for that feature. Visit the Customization Guide on the ArcFM Solution Resource Center for more information.

     

    Geoprocessing Tool

     

    Yet another way to extract feeder information from your data involves the new Export By Feeder geoprocessing tool.

     

     

    Does Feeder Manager 2.0 carry any unique hazards?


    Yes. It’s possible for seemingly innocent actions in ArcMap to cause an exhaustive query of feeder information for every feature in the network. You can cause this expensive and undesirable “full table scan” in a variety of ways. Here are a couple examples that may help you grasp the nature of this particular peril:

    • While using ESRI’s attribute query tool on the Transformer feature class, you could use a where clause such as “Transformer_139.FeederIDs = ‘DX4949’.”
    • You might use the Symbology tab of ESRI’s layer properties window to set up a Unique Values renderer driven by the joined FeederIDs field for a class such as Primary Overhead Conductors. When you click the Add All Values button it results in a full-scale query of FeederIDs values for every feature in that class.
    • Use the ArcFM Locator to find a value in a Feeder Manager 2.0 field while the Locator Option to Return FM2.0 Data is enabled.
    • Use Esri’s Open Attribute Table command on a layer containing a Feeder Manager 2.0 join.
    • Use Esri's Find tool with 'All Layers' selected.

     

    Can I use Feeder Manager 2.0 data on ArcFM Server?


    Yes. With a pair of Esri patches, ArcFM Server 10.2 (not 10.1.1) supports viewing (not editing) Feeder Manager 2.0 data. These patches allow you to publish map services containing data belonging to a plug-in workspace. It is not necessary to install these Esri patches if you do not plan to view Feeder Manager 2.0 data on ArcFM Server:

    • ArcGIS Desktop QFE-102-DT-266424: You need only apply this patch to the machine you use to publish your map service.
    • ArcGIS Server QFE-102-S-266424: Apply this patch to any machine acting as a server for your map service.

     

    These patches are not required if you're running ArcFM 10.2.1, but you still cannot edit Feeder Manager 2.0 data in ArcFM Server.

     

    Because Feeder Manager 2.0 relies on joins, the following join-related known issues may affect viewing Feeder Manager 2.0 data on ArcFM Server:

    • Identify: Features are returned incorrectly when identifying on a layer with an outer join if the feature does not have a related record (ESRI bug #NIM092688).
    • Join Layers: ArcFM display fields are not respected on layers with joins.
    • Related Data: Querying related data does not work if querying on a joined layer.
    • Searches: LIKE searches fail when querying numbers on a layer with a join.
    • Query: Attribute queries that reference joined fields may be inefficient (they may be unable to take advantage of any indexes on the secondary table in the join).

     

    When you publish a map service containing Feeder Manager 2.0 data, you must register the data source of the joined data.

     

    Am I ready to turn off Feeder Manager 1.0?


    We sure hope so. But before you do, make sure you understand the consequences of doing so. Namely, your FeederID, FeederID2, and FeederInfo fields are no longer updated when network features are edited. This causes each of the following things to occur:

    • Feature-linked annotations that reference the FeederID or FeederInfo fields of your network features are no longer kept up to date with Feeder Manager 2.0 (if you have turned off Feeder Manager 1.0’s autoupdaters).
    • Because those fields are no longer updated, any autoupdaters that respond to changes in those fields are no longer triggered.
    • The Select By Feeder tool and the Feeder Locator tool work against those fields too. Consequently, their results will become stale over time.
    • Any applications or integrations that consume those fields (for example, nightly export to OMS) will now consume potentially stale data (assuming you have turned of Feeder Manager 1.0 autoupdaters). You can work around this, for example, by using the Feeder Export geoprocessing tool on a nightly basis, and directing the nightly OMS export process to use the product of that export as its starting point instead of starting directly from the original geodatabase.

     

     

     

    Can I switch back to Feeder Manager 1.0 if I don’t like Feeder Manager 2.0?

     

    Yes. After you turn Feeder Manager 1.0 back on, simply run Trace All Feeders. That’s it. Or, if you happen to know exactly which feeders you’ve edited since the time you turned Feeder Manager 1.0 off, you may get away with retracing only certain feeders, and/or toggling a few carefully selected switchable devices between open and closed.