Releases: ASFHyP3/hyp3
Releases · ASFHyP3/hyp3
HyP3 v9.0.1
HyP3 v9.0.0
Changed
- All failed jobs now have a
processing_times
value ofnull
.
Fixed
- Resolve a regression introduced by the previous release (v8.0.0) in which a processing step could report a negative processing time if the underlying AWS Batch job had a failed attempt that did not include a
StartedAt
field. Fixes #2485 - Upgrade from Flask v2.2.5 to v3.0.3. Fixes #2491
- Specify our custom JSON encoder by subclassing
flask.json.provider.JSONProvider
. See pallets/flask#4692
HyP3 v8.0.0
Added
- A job step can now be applied to every item in a list using a new
map: for <item> in <items>
syntax. For example, given a job spec with agranules
parameter, a step that includes amap: for granule in granules
field is applied to each item in thegranules
list and can refer toRef::granule
within itscommand
field. - If a job contains a
map
step, the processing time value for that step (in theprocessing_times
list in the job's API response) is a sub-list of processing times for the step's iterations, in the same order as the items in the input list. - A new
SRG_TIME_SERIES
job type has been added to thehyp3-lavas
andhyp3-lavas-test
deployments. This workflow uses the newmap
syntax described above to produce a GSLC for each level-0 Sentinel-1 granule passed via thegranules
parameter and then produces a time series product from the GSLCs. See the HyP3 SRG plugin. - The
SRG_GSLC
job type now includes parameter validation.
Changed
- Changes to custom compute environments:
- Custom compute environments are now applied to individual job steps rather than to entire jobs. The
compute_environment
field is now provided at the step level rather than at the top level of the job spec. - If the value of the
compute_environment
field isDefault
, then the step uses the deployment's default compute environment. Otherwise, the value must be the name of a custom compute environment defined injob_spec/config/compute_environments.yml
.
- Custom compute environments are now applied to individual job steps rather than to entire jobs. The
- Other changes to the job spec syntax:
- The
tasks
field has been renamed tosteps
. - Job parameters no longer contain a top-level
default
field. Thedefault
field within each parameter'sapi_schema
mapping is still supported. - Job specs no longer explicitly define a
bucket_prefix
parameter. Instead,bucket_prefix
is automatically defined and can still be referenced asRef::bucket_prefix
within each step'scommand
field.
- The
HyP3 v7.12.0
Changed
- The
hyp3-its-live
deployment now uses a greater variety ofr6id[n]
instances.
HyP3 v7.11.0
Added
- The
INSAR_ISCE_BURST
job type is now available in thehyp3-avo
,hyp3-bgc-engineering
,hyp3-cargill
, abdhyp3-carter
deployments. - The
AUTORIFT
job type is now available in thehyp3-bgc-engineering
,hyp3-cargill
, abdhyp3-carter
deployments.
HyP3 v7.10.0
Added
- Added a new
INSAR_ISCE_MULTI_BURST
job type for running multi-burst InSAR. Currently, this job type is restricted to a specialhyp3-multi-burst-sandbox
deployment for HyP3 operators. However, this is an important step toward eventually making multi-burst InSAR available for general users.
Changed
- Job validator functions now accept two parameters: the job dictionary and the granule metadata.
- Granule metadata validation now supports
reference
andsecondary
job parameters in addition to the existinggranules
parameter. - Burst InSAR validators now support multi-burst jobs.
- Replaced the step function's
INSPECT_MEMORY_REQUIREMENTS
step with a newSET_BATCH_OVERRIDES
step, which calls a Lambda function to dynamically calculate Batch container overrides based on job type and parameters.
HyP3 v7.9.3
Fixed
- Added missing cloudformation:DeleteStack permission to cloudformation deployment role in ASF-deployment-ci-cf.yml .
HyP3 v7.9.2
Removed
- Deleted the
hyp3-pdc
deployment in preparation for archiving the hyp3-flood-monitoring project.
Fixed
- Copied cloudformation permissions from user to cloudformation deployment role in ASF-deployment-ci-cf.yml to address
breaking AWS IAM change when deploying nested stacks via a cloudformation role.
HyP3 v7.9.1
Changed
- The
SRG_GSLC
job now takes in a--bounds
argument that determines the extent of the DEM used in back projection.
HyP3 v7.9.0
Changed
- The
ARIA_AUTORIFT.yml
job spec now specifies the optimum number of OpenMP threads and uses a dedicated compute environment withr6id[n]
spot instances. - The
AUTORIFT_ITS_LIVE.yml
job spec now specifies the optimum number of OpenMP threads. - The
INSAR_ISCE.yml
job spec now reserved 16 GB memory for running the DockerizedTopsApp task. - The
hyp3-a19-jpl-test
,hyp3-a19-jpl
,hyp3-tibet-jpl
, andhyp3-nisar-jpl
ARIA deployments now uses on-demandm6id[n]
instances. - The
hyp3-its-live-test
deployment now uses a greater variety ofr6id[n]
instances.