OU-LE3/GC-SWG 22.03.12 Euclid Consortium Interaction between SWG and SGS-OUs Fabio Pasian & Marc...
-
Upload
jasmin-scott -
Category
Documents
-
view
214 -
download
1
Transcript of OU-LE3/GC-SWG 22.03.12 Euclid Consortium Interaction between SWG and SGS-OUs Fabio Pasian & Marc...
OU-LE3/GC-SWG 22.03.12
EuclidConsortium
Interaction between SWG and SGS-OUs
Fabio Pasian & Marc Sauvage
(EC SGS Project Office)
The presented document is Proprietary information of the Euclid Consortium. This document shall be used and disclosed by the receiving Party and its related entities (e.g. contractors and subcontractors) only for the purposes of fulfilling the receiving Party's responsibilities under the Euclid Project and that identified and marked technical data
shall not be disclosed or retransferred to any other entity without prior written permission of the document preparer.
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumRationale
The SWG and the SGS will constantly interact throughout the mission phases.
During the development of the SGS, the SWGs set requirements on the algorithmic objectives and defines the validation testing of the pipeline module.During operations, the SGS systems produce the data products that form the basis of the SWG work.
The science objectives of Euclid are quite ambitious, and require a complex data processing system.
The interface between the SGS and the SWGs must be clearly defined to avoid biasing the SGS products, or overlap and/or duplication of work between the SGS and the SWGs.
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumDocumentation flow-down
Science Management
Plan(SMP)
Science Operations
Concept(SOCD)
Science ImplementationRequirements
(SIRD)
Science Requirements
Document(SciRD)
Payload Elements
Requirements (PERD)
Mission Requirements
Document (MRD)
Data Processing
Requirements(GDPRD)
SOC Science Implementation
Plan (SOC SIP)
EC Science Implementation
Plan (EC SIP)
EC SGS WPBreakdown and
Description (WPBD)
EC SGS Documentation
Tree
input from EC SWGs
EC SGS
Science Analysis
Implementation(SAID)
SWGs-SGS Interface
Control Doc
Legacy Data Processing
Requirements(LDPR)
EC SWGs
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumRequirements flow-down
Science Management
Plan(SMP)
Science Operations
Concept(SOCD)
Science ImplementationRequirements
(SIRD)
Science Requirements
Document(SciRD)
Payload Elements
Requirements (PERD)
Mission Requirements
Document (MRD)
Data Processing
Requirements(GDPRD)
SOC Science Implementation
Plan (SOC SIP)
EC Science Implementation
Plan (EC SIP)
EC SGS WPBreakdown and
Description (WPBD)
EC SGS Documentation
Tree
Science Analysis
Implementation(SAID)
SWGs-SGS Interface
Control Doc
Legacy Data Processing
Requirements(LDPR)
OU-LE3/GC-SWG 22.03.12
EuclidConsortium
SR/ADSR/AD
DDDD
URUR
TRTR
OMOM
OU Inputs
SPMPSCMP
SVVP/Reviews,
URDSVVP/ST Plan/IT Plan
SSD
SVVP/ST specCODE
SUM
Software System
STD
SDC DevelopmentUR phase - Definition of the user requirements
SR phase - Definition of the software requirements AD phase - Definition of the architectural design
DD phase - Detailed design and production of the codeOM phase - Operations and maintenance
SDC DevelopmentUR phase - Definition of the user requirements
SR phase - Definition of the software requirements AD phase - Definition of the architectural design
DD phase - Detailed design and production of the codeOM phase - Operations and maintenance
CVCV
SURSURScience Inputs
GDPRDLDPRD
Proof of concept
OU DevelopmentCV phase – Concept validation
TR phase - Transfer of the software to operations
OU DevelopmentCV phase – Concept validation
TR phase - Transfer of the software to operations
AT plan
MethodPublication
MethodPublication
POStandard
Document
POStandard
Document
SPMP - Software Project Management PlanSCMP - Software configuration management procedures
SVVP - Software Verification and Validation PlanAT Plan - Acceptance Test ST Plan - System Test Plan
IT Plan - Integration Test Plan URD - User Requirements Document
DPRD - Data Processing Requirements DocumentSSD - Software Specification Document
SUM - Software User ManualSTD - Software Transfer Document
SPMP - Software Project Management PlanSCMP - Software configuration management procedures
SVVP - Software Verification and Validation PlanAT Plan - Acceptance Test ST Plan - System Test Plan
IT Plan - Integration Test Plan URD - User Requirements Document
DPRD - Data Processing Requirements DocumentSSD - Software Specification Document
SUM - Software User ManualSTD - Software Transfer Document
Next Cycle
from the EC SIP 2.2 draft
SWG DevelopmentSUR phase - Definition of the science user requirements
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumSWGs-SGS ICD
Science Management
Plan(SMP)
Science Operations
Concept(SOCD)
Science ImplementationRequirements
(SIRD)
Science Requirements
Document(SciRD)
Payload Elements
Requirements (PERD)
Mission Requirements
Document (MRD)
Data Processing
Requirements(GDPRD)
SOC Science Implementation
Plan (SOC SIP)
EC Science Implementation
Plan (EC SIP)
EC SGS WPBreakdown and
Description (WPBD)
EC SGS Documentation
Tree
Science Analysis
Implementation(SAID)
SWGs-SGS Interface
Control Doc
Legacy Data Processing
Requirements(LDPR)
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumThe SWGs-SGS ICD
The ICD originates from discussions between OU-LE3 and the SWGs.
Draft 0.5, distributed to the OU+SDC leads, and SWG coords was iterated inside the SGS PO.
Comments are expected and welcome.
It's short (only 7 pages of meaningful text)!
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumThe interface entities
The ground segment Organization Group:The SGS PO (manager, scientist, system team lead + support team).The OU leads.The SDC managers.
The Science Working Groups coordinatorsThe leads of the two primary cosmology probes SWGs (4 persons).2 rotating representatives for leads of the legacy, theory and simulation SWGs.
These two representative bodies are in charge of taking care of the interface issues. See the EC Management Plan for names (wiki).
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumEC SGS Management
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumA key concept: avoid confirmation bias
How? try to maintain cosmology "independence" and/or "blindness" in the SGS pipeline.
SGS codes should refrain from relying on cosmology assumptions ("independence"), and their validation should not be done against a given cosmology ("blindness").Requests to depart from that, (e.g. use or produce absolute quantities) should be made known to the Organization Group, to be discussed with the SWG coords, and use the reference cosmology maintained by the SWG coords.This is/will be a highly debated item in discussions between the SGS and the SWG. Is it enough to avoid a confirmation bias? likely not.
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumRequirement driven development
General principle for SGS data processing pipeline development:
SWG formulates requirement for the production of data with specified properties, as well as tests that have to be run to validate that part of the SGS pipeline.OU researches algorithms that fulfill the requirement, and once the SWG has accepted that the algorithm is an acceptable candidate, passes to the SDC-Dev the algorithm description and a test "plan" for verification and validation.OU algorithms suggestions can only be refused by SWG because they do not meet the requirement.
Each SGS WP should be connected, directly or through other WPs to a requirement on the SGS.
"Free-floating" SGS WP could be a worry and should be tracked down.
However. WPs are management tools. Management WPs, or finer-grained
subdivision of work (e.g. across countries) are a matter of SGS decision.
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumCode practice
No coding standards at OU levelOUs are not required to produce code at all (algorithms, prototypes + test data)
Coding standards/uniformity required at SDC levelcodes need to be scalable, maintainable, moveable.codes will adhere to some form of GPL, but intellectual "property" should be maintained by applying to the codes rules similar to publications (policy to be set).
Request by SWG to use the SDC to run their codes should be handled by the SGS organization group.
The primary mission of the SDCs is to develop and run the SGS pipeline.SWG SAID is a good read for SGS to anticipate these demands.
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumData access
Question: is it always harmless to use Euclid data to develop SGS modules?
Data access should stay compatible with the primary missions of the SGS.
Some issues remain to be cleared out, e.g. regarding simulated data produced by the SGS.
OU-LE3/GC-SWG 22.03.12
EuclidConsortiumConclusions
Currently, the SWGs-SGS ICD is a living document. Feedback is needed.
SWGs-SGS interrelations are important, key to the success of the mission.
ICDs are built to define the interfaces between groups.
Interrelations ≠ Interfaces
IMPORTANT: let’s not build useless/harmful fences between (virtual) groups!
OU-LE3/GC-SWG 22.03.12
EuclidConsortium