handle FT of 0-dim Array

[juliasloan25]

Purpose

closes #482
bumps patch version so we can make a release with fix

tested in ClimaAtmos here: CliMA/ClimaAtmos.jl#2968 (passing build)

[sriharshakandala]

Would this work?

    bounds = DA([
        # liquid particle size lower bound for LUT interpolation
        FT(ds["radliq_lwr"][]),
        # liquid particle size upper bound for LUT interpolation
        FT(ds["radliq_upr"][]),
        # factor for calculating LUT interpolation for liquid particle
        FT(ds["radliq_fac"][]),
        # ice particle size lower bound for LUT interpolation
        FT(ds["radice_lwr"][]),
        # ice particle size upper bound for LUT interpolation
        FT(ds["radice_upr"][]),
        # factor for calculating LUT interpolation for ice particle
        FT(ds["radice_fac"][]),
    ])

[charleskawczynski]

I don't think so:

julia> Float64(rand(3))
ERROR: MethodError: no method matching Float64(::Vector{Float64})

Closest candidates are:
  Float64(::Int128)
   @ Base float.jl:200
  Float64(::Bool)
   @ Base float.jl:165
  Float64(::Int16)
   @ Base float.jl:159
  ...

Stacktrace:
 [1] top-level scope
   @ REPL[8]:1

I would actually prefer using an array constructor, instead of recasting after the array has been made:

julia> Array{Float32}(rand(3,3))
3×3 Matrix{Float32}:
 0.101806  0.417171  0.951682
 0.249531  0.359648  0.873839
 0.586299  0.165479  0.341307

So, does Array{FT}(ds["radliq_lwr"]), work?

[charleskawczynski]

Ah, I missed the getindex call in @sriharshakandala's suggestion. That should work too, assuming the result is of the same type that we expect

[juliasloan25]

It looks like that works for the cases we're currently testing. Would this work for an array of length > 1 though? I get:

julia> arr = Array{Float64}(undef, 2)
2-element Vector{Float64}:
 2.2080290545e-314
 2.2080785164e-314

julia> FT(arr[])
ERROR: BoundsError: attempt to access 2-element Vector{Float64} at index []
...

Also, do we still want to keep the Array conversion so we don't create a CuArray on GPU? Or would it create an Array anyways because it's reading from a NetCDF file?

[sriharshakandala]

In this specific case, these are all scalars!

[charleskawczynski]

Sorry, I think I wasn't clear, I meant for my suggestion to be:

    bounds = DA([
        # liquid particle size lower bound for LUT interpolation
        Array{FT}(ds["radliq_lwr"]),
        # liquid particle size upper bound for LUT interpolation
        Array{FT}(ds["radliq_upr"]),
        # factor for calculating LUT interpolation for liquid particle
        Array{FT}(ds["radliq_fac"]),
        # ice particle size lower bound for LUT interpolation
        Array{FT}(ds["radice_lwr"]),
        # ice particle size upper bound for LUT interpolation
        Array{FT}(ds["radice_upr"]),
        # factor for calculating LUT interpolation for ice particle
        Array{FT}(ds["radice_fac"]),
    ])

This whole thing does look odd, though. I think perhaps @sriharshakandala's suggestion is best assuming these are all 1-element arrays.

[juliasloan25]

It seems like ds["var"] is sometimes returning a 0-length array with the CommonDataModels release, so I'm not sure if we can rely on them being scalars. Though with Sriharsha's fix, the test that was previously failing does now pass, even though I get an error when trying to access a 0-length array with []

julia> arr
Float64[]

julia> arr[]
ERROR: BoundsError: attempt to access 0-element Vector{Float64} at index []
...

[sriharshakandala]

The changes to the LookUpTables.jl looks good to me. Thanks!

[juliasloan25]

@sriharshakandala @charleskawczynski the MacOS test are hanging/timing out, but the ubuntu tests are passing. Is it okay to merge this anyway?

[charleskawczynski]

@sriharshakandala @charleskawczynski the MacOS test are hanging/timing out, but the ubuntu tests are passing. Is it okay to merge this anyway?

Yeah, that's fine. I think there's been issues with GH runners lately.