| Alerting | Alerting | See the related dataType for further information. | |
| AllowPartialResolution | str | Whether to create PPOs if only a subset of them satisfy their cardinality constraints. The default behaviour is to create PPOs only if all of them satisfy their cardinality constraints, as defined by the plan GroupedBy/LinkedBy specifications. A partial resolution allows the plan solver to create the subset of PPOs which have their input data available, regardless of plan completeness. | |
| AutomaticTriggering | AutomaticTriggeringParameters | If present, this element indicates that this plan should be processed using an automatic triggering strategy. The goal of automatic triggering is to reduce manual operations and maximize the usefulness of pipeline resources by creating PPOs only when a pipeline is at its optimal readiness state. This implies checking PF-specific business rules such as tile/observation coverage and remaining time before next input data. | |
| Comment | str | Comment : Free text description of the plans intent for creator convenience. | |
| Creator | str | Creator : The creator is the EAS login used by the Euclid user to fill the Plan form from COORS GUI. To access the COORS client the user must first log into it which ensures he has access to ingest objects into the EAS. Thus this field can be automatically supplied via COORS client with the EAS username of the person creating the plan through the COORS client and ingesting it into the EAS. | |
| DataSetRelease | str | This release element is inherited from the Plan definition and could be (depending on the context of the processing Plan): - SIM datarelease for a SIM pipeline - Specific run of an IT or SC challenge or a cycle during pre integration or pre production - Specific set of plans built for some specific scientific analysis: calibration campaign, scientific analysis - ... Enable to define a consistent set of data products (used to select a unique instance of a given data product at COORS level) this data product belongs to (not to be confused with the specified DataRelease or intermediateDataRealease by ESA that could be defined a posteriori | |
| EuclidPipelineSoftwareRelease | str | Configuration of the overall Euclid pipeline, representing the aggregation of elementary PFs plus MDB release, ...; This version should be the output of the SGS CCB. | |
| ForceComputingResources | str | See ForceComputingResources element of pipelineProcessingOrder type. | |
| Id | str | Id : This Id is generated by the EAS service that ingests the PP from COORS GUI, COORS should initialize this Id and EAS should update and ensure uniqueness of the running number. This Id is unique in the SGS and the following pattern fullfiled by EAS ensures this uniqueness. [PIPELINE]-[PURPOSE]-[USER]-PLAN-[NUMBER] where [PIPELINE] is the PipelineDefinition.Id which is in the form [PIPELINE_NAME]-[VERSION],[PURPOSE] is the one defined below, [USER] is the EAS username of the person creating the plan through the COORS client and ingesting it into the EAS, [NUMBER] is a running number. e.g : EUC_SIR-PIPELINE-SC2_V0.1-PRODUCTION-RCOLLINS-PLAN-1 | |
| InputDataSetPlan | InputDataSetPlan | InputDataSet: This replicates the InputDataSetDefinition from the PipelineDefinition datatype(from package tsk) OR the parametrized query. | |
| Message | str | Message : Any success or error messages returned by the EAS COORS Plugin run that generated PPOs for this Plan. | |
| PipelineExecEnv | PipelineExecEnv | Execution environment for the pipeline. If not set the plan is used for data transfer. | |
| PlanActivationInterval | int | This Plan Activation Interval ( to be interpreted in hours) is coupled with the PlanStartDate - PlanEndDate metadata, this should be used to trigger the EAS query to retrieve new input products made available into the EAS since the last query. This should allow to automatically create new PPOs based on new key products archived. It should be noted that only presence of new input products should trigger new PPO. | |
| PlanEndDate | datetime | PlanStartDate - PlanEndDate : Plan can be create in advance of the input data being available [for example, one could prepare a MER plan in advance of the VIS, NIR etc. pipelines being completed] and then the plan would remain "active", continually [interval to be decided...] looking for new input data and generating PPOs for this data when available, until the plan is deactivated. Hence start and end date are control parameters: only keep the plan active (and hence looking for new input data) between these date ranges. Users through the COORS GUI form could manually update the date ranges plan to be deactivated and hence it both controls the plans active status and records when it has finished. Default start date in the client is date of now and a default end date could be : current date plus one week. These two dates are optional and interpreted thanks to the TriggerPipeline strategy. | |
| PlanInputProducts | PortProductsRefSet | PlanInputProducts : This replicates the taskProductsSet datatype from the PipelineDefinition datatype(from package tsk). This set defines the list of unique ProductsId per data productType and its portName. That is the result of the query per data product given by EAS with the search attributes defined in the InputDataSetDefinition. | |
| PlanStartDate | datetime | PlanStartDate | |
| Purpose | str | Purpose : This is an enumerated that should be interpreted by IAL as a priority level for all the PPOs and all its child processing jobs. See the associated type for the possible values. | |
| Status | str | Status : Valid values of a plans status are listed below: NEW: A new plan created by COORS user. This is a temporary status of a plan that has not yet attempted to create any PPOs, and plans with this status are allowed to be deleted. READY: An inactive plan, which has completed creating its PPOs, but not yet allocated any. Plans with this status can also be deleted because PPOs have not yet been allocated to their SDCs for execution. ABORTED: A plan that has failed to create PPOs, with the error message reported in the message field. SCHEDULED: Active plan, but without active PPOs due to incomplete availability of input data (e.g. a "trigger plan"). This is a user chosen status in the COORS UI. It will remain in this state until the COORS backend service finds the complete input data set necessary to generate at least one PPO. ALLOCATED: Active plan with associated active PPOs, but not yet executing. If the complete input data set is available at the plan review stage and the user chooses to execute the plan immediately then COORS will update the plan and PPOs in the EAS to this plan status. RUNNING: Active plan with some PPOs still executing/complete and none have an error or failed status. The COORS backend service checks the PPO status updates made by the IAL to determine this status. If this is a trigger plan it remains active and open to generating new PPOs when new input data becomes available. ERROR: Plan still active with currently executing PPOs, but at least one PPO is in an error or failed state. The COORS backend service checks the PPO status updates made by the IAL to determine this status. FAILED: Plan deactivated with no currently executing PPOs and at least one PPO failed. The COORS backend service checks the PPO status updates made by the IAL to determine this status. COMPLETED: Plan deactivated with all PPOs in the completed state (no PPOs failed: SUCCESS). The COORS backend service checks the PPO status updates made by the IAL to determine this status. | |
| TargetSdc | str | TargetSdc : This reflects the SDC tag that is mentioned into the PipelineDefinition, if this TargetSdc is set to All or missing so this is the default strategy based on Observation distribution. If some users want to create a PP while imposing a given targetSDC for all PPO they update this element that supersedes the targetSDC at PPO level. | |
| TriggerPipeline | str | TriggerPipelineStrategy: This element defines the triggering strategy and how to use the following StartEnd dates and PlanActivationInterval. The different strategies are: ONCE: Plan runs once when user submits the Plan and its inputQueryPlan to EAS, PlanStartEndDate and Interval are not used, ACTIVATION_ONCE_ON_DATES: Plan runs once the PlanStartDate is reached, the InputQueryPlan are executed and the user can submit the plan and its PPOs once, PlanEndDate and Interval are not used AUTOMATIC_REPROCESS: Plan is automatically reprocessed when new data that meet the input query criteria are available in the EAS so that new PPOs are eligible. This is a long running plan. PlanStartEndDate and Interval are not used, AUTOMATIC_REPROCESS_ON_DATES: Plan is automatically reprocessed when new data that meet the input query criteria are available between two consecutive dates at PlanActivationInterval. This automatic re triggering will stop once PlanEndDate is reached. PlanStartEndDate and Interval are needed. So that Plans which are supposed to be reprocessed on ingest of new data products should be specially marked, with TriggerPipeline set to AUTOMATIC_REPROCESS, AUTOMATIC_REPROCESS_ON_DATES. Plans will be selected and for their new input data products will be checked - is anything ingested immediatly available or available in the PlanActivationInterval. If so Plan will be re-run and to prevent repeating of the same PPO it should be checked that PPOs created on re-run were not created before. This shall be done by COORS interface. | |
