glwagner / dao.jl Goto Github PK

After this line:

a parameter array is apparently used to initialize KPP.Parameters:

function model_run(params,ni,nt)
    parameters=KPP.Parameters( CSL = params[1],
       Cτ = params[2],
      CNL = params[3],
    Cstab = params[4],
    Cunst = params[5],
     Cb_U = params[6],
     Cb_T = params[7],
     Cd_U = params[8],
     Cd_T = params[9],
      CRi = params[10],
      CKE = params[11],
       Cn = params[12],
    Cmτ_U = params[13],
    Cmτ_T = params[14],
    Cmb_U = params[15],
    Cmb_T = params[16])
    model = KPP.Model(N=128, L=100.0, stepper=:BackwardEuler,parameters=parameters)

If this input params were a dictionary, these lines would become

function model_run(param_dict, ni, nt)
    parameters = KPP.Parameters(param_dict...)
    model = KPP.Model(N=128, L=100.0, stepper=:BackwardEuler, parameters=parameters)

I think the second version is better.

In the MCMC algorithm the outputs of the forward map are typically discarded. It would be nice to have an automated way of recording the probability distribution of the forward map(s) and saving it in the end (without just recording the output of the forward map, which may be too much data).

More specifically it would be nice to visualize the probability density associated with the temperature field in KPP for fixed boundary conditions and a given point in time. This would be the probability density of the function \rho(z, T | boundary conditions, time) where $T$ is the temperature profile. It would be visualized at as a 2D histogram / contour plot and would tell us what a ``random" temperature profile looks like, as well as the uncertainty associated with a temperature field given the uncertainty with respect to the parameters

A few suggestions:

1. Separate the analysis of the Oceananignas NetCDF output and the UQ. In particular, let's create an array of 1D profiles of the LES data and save them separately. I propose we use

https://github.com/JuliaIO/JLD2.jl

2. The first processing step should be to convert the 1D JLD2 data from the LES to OceanTurb fields.

3. We could initialize the OceanTurb profile with the LES data?

4. I couldn't figure out why the parameters have to be stored in an array, as here:

params = [0.1 0.4 6.33 2.0 6.4 0.599 0.135 1.36 -1.85 0.5 2.5 4.32 0.3 1e-11]
parameters = KPP.Parameters(
    Cε = params[1], Cκ = params[2], CN = params[3], Cstab = params[4], 
    Cunst = params[5], Cb_U = params[6], Cτ_U = params[7], Cb_T  = params[8],
    Cτ_T = params[9], Cd_U = params[10], Cd_T = params[11], CRi = params[12], CKE = params[13]
)

Also, since this just uses defaults, its no different from writing

parameters = KPP.Parameters()

which is easier, presumably.

5. To 'splat' parameters we can do

params_dict = Dict(:Cstab => 2.1)
parameters = KPP.Parameters(; params_dict...)

or something like that.

But I think what we really need is some pseudocode to indicate what we are trying to do? Then we can figure out the julia algorithm to do it.

6. Let's use this function (for example):

function free_convection_model(N, L, parameters, heat_flux, γ)
    model = KPP.Model(N=N, L=L, parameters=parameters)
    T₀(z) = 20 + γ*z
    model.solution.T = T₀
    temperature_flux = heat_flux / (model.constants.ρ₀ * model.constants.cP)

    model.bcs.T.top = FluxBoundaryCondition(temperature_flux)
    model.bcs.T.bottom = GradientBoundaryCondition(γ)

    return model
end

6. Finally, let's modify the default Constants in OceanTurb to be identical to Oceananigans.

Should AdaptiveExponentialSchedule objects

have a temperature attribute so that

There are a few source files in /src (convenience.jl and uq_kpp.jl), but the code is not contained inside modules and no functions are exported in Dao.jl. These source files look like examples to me.

We should develop software and functions for UQ that permit users to write simple, clear, short and concise scripts that perform elementary UQ.

We may also want to develop 'interface' modules that interface with codes like OceanTurb, though I'm not sure this is necessary (it would be better to ask codes like OceanTurb to implement the functionality we need so that interfacing is trivial).