CliMA / CliMA/ParameterEstimocean.jl

`computed_fields` for `SyntheticObservations`

Open
#216 1 comment 0 reactions 0 assignees View on GitHub
🤥 enhancement
Dominant language
Julia
Stars
22
Forks
6
PR merge metrics
No merged PRs in 30d

Description

Say that I want to calibrate CATKE using the mismatch between the _gradient_ of observed and modeled TKE, rather than the absolute value. This is reasonable if we really care about the "shape" of the profile, rather than its absolute magnitude.

For this I think we can allow users to specify transformations on data that get loaded into `field_time_series`. This is what it might look like:

```julia
dz_e = Computation(e -> ∂z(e), inputs=:e)

obs = SyntheticObservations(data_path, field_names=(:b, :e), computed_fields=(; dz_e))
```

For shear we might write

```julia
shear = Computation((u, v) -> sqrt(∂z(u)^2 + ∂z(v)^2), inputs=(:u, :v))
obs = SyntheticObservations(data_path, field_names=(:b, :e), computed_fields=(; dz_e, shear))
```

under the hood, we can first load the "file-based" `FieldTimeSeries`, and then use that data to make the list of `computed_fields`. The first argument to `Computation` is a function that transforms `dependencies` (one of or a list of the fields that were loaded from file) into another field or abstract operation.

It's probably also possible to design a macro that allows us to write (since the code gives us the names of the `inputs`.

```julia
shear = @computation (u, v) -> sqrt(∂z(u)^2 + ∂z(v)^2)
```

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the SyntheticObservations and field_time_series paths described in the issue, then trace how file-based FieldTimeSeries data is loaded. Determine how computed_fields should transform loaded dependencies and whether the proposed @computation syntax is in scope. Done means users can define derived fields such as gradients or shear from loaded fields.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.