[Bug]: PCM should not be mixing HH and VV polarization in a single PGE run for DISP-S1 processing

[hhlee445]

Checked for duplicates

Yes - I've already checked

Describe the bug

Testing DISP-S1 sciflo jobs failed with following errors when we provided inputs with a mix of polarization values (HH & VV)

Exception Type: <class 'RuntimeError'>
Exception Value: Input precondition failure: More than one (2) polarization values parsed from set of input CSLC granules
Traceback (most recent call last):
File "/home/ops/verdi/ops/chimera/chimera/precondition_evaluator.py", line 173, in evaluate
job_params.update(cls_object.run(self._pge_config.get(ChimeraConstants.PRECONDITIONS, list())))
File "/home/ops/verdi/ops/chimera/chimera/precondition_functions.py", line 17, in run
self._job_params.update(getattr(self, func)())
File "/home/ops/verdi/ops/opera-pcm/opera_chimera/precondition_functions.py", line 418, in get_disp_s1_polarization
raise ValueError(f'More than one ({len(unique_polarizations)}) polarization values '
ValueError: More than one (2) polarization values parsed from set of input CSLC granules

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/ops/verdi/ops/sciflo-1.3.6/sciflo/grid/workUnit.py", line 130, in run
result = self._run()
File "/home/ops/verdi/ops/sciflo-1.3.6/sciflo/grid/workUnit.py", line 172, in _run
return func(*funcArgs)
File "/tmp/scifloWork-ops/sciflowuid-17568423-06113760-0809132024-96ee66ea968758bc29043f24baf55ba8/input_preprocessor.py", line 28, in process
output_context = pre_cond_evaluator.evaluate()
File "/home/ops/verdi/ops/chimera/chimera/precondition_evaluator.py", line 178, in evaluate
raise RuntimeError("Input precondition failure: {}".format(e))
RuntimeError: Input precondition failure: More than one (2) polarization values parsed from set of input CSLC granules

What did you expect?

PCM should ever be providing inputs with a mix of polarization values to trigger DISP-S1 sciflo jobs.

Reproducible steps

No response

Environment

No response

[philipjyoon]

After discussing this w the SDS team, here is our design:

• We would introduce a flag to daac_data_subscriber.py named --disp-polarization. This will have default value of VV. But HH can be passed in if we ever want to process using HH
• Forward lambda will have an env var named DISP_POLARIZATION that maps to this new parameter. Default value is VV
• The historical processing database only contains VV bursts. If we ever want to process HH products, we must receive and use a different historical database that only contains HH polarization bursts
• CSLC query job will filter out any bursts returned from CMR by this polarization

[philipjyoon]

@LucaCinquini @sjlewis-jpl and I discussed this today. While this HH option is preferable it does take non-trivial development and testing time. We are expecting that the chances of the mission wanting to process HH data is very low.

Therefore, we will simply put a hard filter for VV data this time around. We will skip any HH data we get from CMR - it will be as if they don't exist at all. The current historical database json only contains VV granules. If the unlikely future event that the mission wants to process HH data, we will implement the design mentioned here in comment above.

[philipjyoon]

Completed as noted here