Support parameter ranges and distributions in target definitions file

[gavinmacaulay]

Have the ReferenceModels class implement the parameter range and distribution definitions in the target definitions.toml file.

[jmjech]

I was thinking about this and the ways we used to generate "TS" and visualize the results. In this case, I'll use "TS" as a generic term for the different types of scattering amplitudes, e.g., σ_bs, reduced scattering length (RSL), TS (10*log₁₀(σ_bs)), ...

I'll use "L" as some length measurement of the target. It can be length of the major/semi-major axis of an oblong target (L) or radius (a) for a sphere.

"TS"("L"): "TS" vs "L" at a specific frequency (f). "L" is given as a range from "L"_min to "L"_max at "L"_interval The abscissa can also be non-dimensional, e.g., L/λ, ka (k=2π/λ), ...

"TS"(f): "TS" vs frequency at a specific "L". "TS" is given as a range from "TS"_min to "TS"_max at "TS"_interval The abscissa can also be non-dimensional, e.g., L/λ, ka (k=2π/λ), ...

"TS"(θ): (tilt angle) "TS" vs tilt angle (θ) at a specific f and "L". θ is given as a range from θ_min to θ_max at θ_interval

"TS"(φ): (roll angle) "TS" vs roll angle (φ) at a specific f, "L", and θ. φ is given as a range from φ_min to φ_max at φ_interval We actually incorporated this into the "ambit" where we looped through roll and tilt.

"TS"("L" and θ) 3D graph of "TS" vs length and tilt angle at a specific f. θ is given as a range from θ_min to θ_max at θ_interval. "L" is given as a range from "L"_min to "L"_max at "L"_interval

These can be generated at a constant g and h, or over variable g and h.

I'm still working on how we implement them in the code and when we get to a web-based interface with graphics.

[gavinmacaulay]

I've been testing out a table-based way of giving model parameters to the models (hinted at in #5), where each row of the table (a Pandas DataFrame in my testing) specifies the scalar parameters to use to generate a single TS estimate. It is then trivial to have Pandas apply the model code to each row in turn, or have a multi-processing module spread them across many CPUs (as wished for in #4).

Specifying the model parameters in a dictionary, such as this:

params = {'medium_rho': 1000,
          'medium_c': 1500,
          'f': np.linspace(12, 100, num=400) * 1000,
          'theta': np.arange(0, 180, 1),
          'a': 0.07,
          'target_c': 1450,
          'target_rho': 1250}

makes it simple to convert to a DataFrame containing the Cartesian product of those parameters (e.g., all the combinations) - it's one line of code:

pd.DataFrame(np.array(np.meshgrid(*tuple(params.values()))).T.reshape(-1, len(params)), columns=params.keys())

It also generalises well if more of the parameters are array quantites. For example, the 3D theta/phi for a range of frequencies would be:

params = {'medium_rho': 1000,
          'medium_c': 1500,
          'f': np.linspace(12, 100, num=400) * 1000,
          'theta': np.arange(0, 180, 1),
          'phi': np.arange(-90, 90, 1),
          'a': 0.07,
          'target_c': 1450,
          'target_rho': 1250}

[jmjech]

Very nice. There are advantages to pandas.

It seems the initial dictionary could be generated from reading an input file in a yaml, json, xml, toml, ... format that the user provides. I don't think we would need to define the structure of that input file (I think that just requires adding ingest and parser functions), but the naming convention should be standardized.

[gavinmacaulay]

Agreed - a particular input file format wouldn't then be required. The code can be readily written to accept a dictionary, a DataFrame, or a DataArray (Xarray) as long as they use the specified parameter names (keys, column names, coordinate names, respectively).