ATL19 all orders with customization failing (Earthdata Search, Variable selection)

DAS-1692 - Getting issue details... STATUS

Related tickets:

  • DAS-1692 - ATL19 all orders with customization failing - A DAS fix vs EDSC-3583
  • EDSC-3583 (ECS-2302) - ATl19 - unable to unselect groups of variables
  • DAS-1698 - HEGService variable expansion should check for excluded datasets (ATL-19)
    (partial complement to DAS-1692)
  • DAS-1694 - ATL14_AA version 2 sometimes fails when all datasets are selected.
    • Separate issue within HEG, not really the same thing,
      but written at same time and using similar language


Note: 12/1/2022 - EDSC started work on EDSC-3583

Happens for the following use/test-case:  

search.uat.earthdata.nasa.gov 
=> search on "ATL19 DEV07" 
=> select any granule ("+") and click on Download 
=> select Customize - ESI 
=> Band Subsetting (Optional) 
=> click on e.g. ATL19 / ds_surf_type / mid_latitude.  

The check-box does not change and the selection of sub-items does not change.

(https://search.uat.earthdata.nasa.gov/projects?p=C1243051453-EDF_DEV07!C1243051453-EDF_DEV07&q=atl19%20dev07&tl=1668440799!3!!)

Note:

  • The group: …/mid_latititude  has a nested 3D variable:  dot_hist_albm   which is disabled
  • dot_hist_albm is represented as a group itself, with 601 sub-entries (“bands” or “band variables”)
    (The so-called flattening of 3D variables into a group of 2D variables).

There are multiple interrelated issues

  • HEG does not handle 3D variables properly
    - Instead, flattening 3D variables to a set of 2D variables.
      • Decision made to not fix HEG, but work-around where necessary
      • Allow flattening where appropriate (SMAP, some ICESat-2 cases)
      • Disable 3D variables where necessary - large extent of 3rd (bands) dimension
    • HEG generates the list of variables for a granule - HegTool
    • HEG-Java code is used to generate the "Job List" (prm file) for per-variable processing.  

  • EDSC has an issue with nested “excluded” variables
    • Excluded is a DAS concept that means: disabled from selection, often conditionally (“relevancy” settings).  Conditions evaluate other selected customization options such as projections or format selections.  In this case, the 3D variables are always disabled, no conditions defined that would evaluate to true for relevancy/enabled status.
    • A parent group containing an excluded/disabled 3D variable cannot be selected/de-selected.  
      • In this case, the parent group is enabled - not excluded
      • The 3D variable itself is represented as a group with sub-elements - “flattened” 2D variables.
      • The list of sub-element variables are all also excluded/disabled.
    • Not sure if this occurs with a singular disabled variable (not group), but I suspect this simpler test case is well tested and works ok.
  • Note that EDSC also, currently, will "prune" the variable list in generated ESI/EGI service requests when all of the sub-elements are selected.
    • When all sub-elements are selected, only the group-level reference is stated in the ESI/EGI service request.
    • This reduces the request complexity, but complicates our options to work-around the problem, as discussed below.
    • EDSC will not prune in the presence of "excluded" variables (conditionally enabled, condition may be always true or always false).
  • HegService (Tool Adapter for HEG within ESI/EGI) also provides a variable list expansion function
    • when the variables requested include group-level references
      •  including 3D variables being expanded as “flattened” 2D variables.
    • that does not consider exclusions
    • This hasn’t been a problem, but it does limit work-arounds to above.

  • The Echo-Forms Generator generates the (sometimes extensive) sub-variable lists for 3D variables, even when the base variable has been excluded in all cases (no enabled conditions).
    • The presence of excluded (disabled) variables has the hidden benefit of forcing EDSC to generate requests with enumerated variable lists, vs. pruning requests to the group level (which causes problems with HegService).
    • Generally not a problem, except - limits work-arounds to above
    • The variable selection list is longer than necessary - including hundreds, thousands collectively, of disabled (excluded) variables.  EDSC performance, fortunately, or unfortunately depending on your perspective, has not been adversely affected.

Resolution alternatives

  1. ** Fix Earthdata Search

  2. Use DA-GUI to disable variables (vs. conditional exclusion table)
    • When Disabled in DA-GUI, Variable is removed from consideration
    • Disabled vs. Excluded - these are different settings options
    • Disabled by DA-GUI means variable is not seen within the Echo-Form, and not presented within Earthdata Search for customized selection/de-selection.
    • Note: Echo-Forms, Earthdata Search presentation and Earthdata Search request generation may make a request assuming the lack of other variables - requests incorrectly made with group selection or pruned to the group level.
    • Disadvantage:  HegService may then expand without consideration of 3D vars that have been excluded.

  3. Use DA-GUI to disable all but one leaf variable
    • Not available: Actually - DA-GUI does not present expanded list of 3D variables, thus not offering the option to disable or enable just one.
    • If available, the intent was to leave one leaf variable enabled (DA-GUI), but excluded (disabled) in the exclusions table.  This would force Earthdata-Search to enumerate the selected-variables (not use group level).

  4. *? Modify Echo-Forms generation to not expand the list of sub-elements for 3D variables if an exclusion in all cases exists
    • But we run into the HegService expansion behavior described above.
    • If we do not expand at all, the form is much more compact
    • If we limit expansion to one sub-element, which is also disabled, this is an odd, but technically functional resolution.

  5. Implement exclusions in HegService
    • Quite complicated - in part because HegService does not work directly with the Data-Access database where the exclusions table is maintained.
    • SimpleInventoryInterface (SII) is used for database access.
    • Also, HegService builds upon legacy HEG Java code to implement variable group expansion.
      • An extension to SII would be required for this fix 
      • + updates to HegService to read and interpret.
      • This presents its own complications.
  6. *? Implement a “hack” in HegService that uses a sufficient but simplistic heuristic
    • ATL19 has 3D variables with 600+ “bands”
    • I suspect a check on the number of bands involved in “field-level” (3D) expansion could trigger an exclusion in this code - if e.g., > 100 - do not expand list of variables.
    • Our problem exists in the specific case of 3D variables that are too big for processing as “flattened 2D” variables in a group.
    • All other cases of flatting involve 3D variables with ~ 5 or 6 bands.
    • The hack works because of this distinction in size of 3D variables being disabled.

  7. *? Implement a fix in HEG - HegTool, Resample(?)
    • HegTool does not include large 3D variables in variable list for granules
      • "ConfigureDataObjects" does not list large 3D variables
      • DA-GUI and EchoFormsGenerator do not see large 3D variables
      • EDSC does not see large 3D variables, does not list variables in EGI/ESI requests

** a preferred option

*? is a viable option but a bit of a hack

  • No labels