Git Product home page Git Product logo

linefitting's Introduction

LineFitting

Tests of line fitting algorithms, with a focus on different strategies for multicomponent fitting. Description of key routines:

  • nh3_testcubes.py -- Create a set of test cubes for running multicomponet fitting tests on (see "GAS Test Cubes" below for more details).

  • analysis_tools.py -- Contains tools to analyze test results. A test result can be initialized as a TestResults object for quick analysis.

  • analysis_template.ipynb -- A template to run identical analysis on different fitting methods. This notebook wraps around analysis_tools.py and uses example_result.txt as an example.

  • example_result.txt -- The example test result to be used in tandem with analysis_template.ipynb.

GAS Test Cubes

A test set of 10,000 cubes are generated via nh3_testcubes.py for a benchmark comparison between different line-fitting algorithms. A synthetic ammonia spectrum modelled by either one or two velocity slabs is generated at the central pixel of each test cube. The remainder pixels in the cube are filled with models nearly identical to that of the center pixel, differ only by a small velocity offset for individual velocity slabs.

Peformance of the line-fitting algorithms are compared against one another statically based on their fits to the central pixel of the cubes. Default random seed for the cube generation is set to 42 to accommodate further needs to make spectrum-to-spectrum comparisons.

Distributions of the Test Set Parameters

The physical parameters used to generate the test cubes are randomly drawn from the following distributions for each velocity slap:

  • Velocity centroid:
    • First slab: uniformly distributed in the range of [-2.5, 2.5) km s-1.
    • Second slab: uniformly distributed in the range of [-2.5, 2.5) km s-1, with respect to velocity centroid of the first slab.
  • Linewidth:
    • Quadrature-sum of the thermal and the non-thermal linewidths
    • Thermal linewidth: 0.08 km s-1
    • Non-thermal linewidth: log-normally distributed in the natural log space. The distribution has an 1-sigma range of [-3.8, -0.8) log(km s-1) in the natural log space.
  • Column Density:
    • Uniformly distributed in the log10 space in the range of [13, 14.5) log(cm-2).
  • Kinetic temperature:
    • Uniform distribution in the range of [8, 25) K

linefitting's People

Contributors

mcyc avatar low-sky avatar jpinedaf avatar

Watchers

Adam Ginsburg avatar James Cloos avatar avatar avatar Rachel Friesen avatar Jared Keown avatar avatar

Forkers

jpinedaf jakeown low-sky

linefitting's Issues

Modularizing nh3_testcubes.py

As discussed earlier, nh3_testcubes.py can benefit from being modularized, particularly as a mean to avoid being overloaded with special use cases.

I can work on it unless anyone else wants to volunteer.

Define Initial set of comparisons for multicomponent fits

What are the tests that we should carry-out?

Here is an initial list, but we need to see what else is needed:
-Spatial coverage of 0-, 1-, 2-, or N-components
--> Degree of agreement or disagreement
-V_LSR in the 1-component model
--> they should give the same value
-V_LSR and \sigma_v in places where both approaches show 2-components
--> Compare the results for the narrowest and widest components? Or use the V_lsr as the anchor point?

Constraining parameter gradients for the test set

Should we narrow the range of gradient values used for our test set? The current 1-sigma range values for temp, sigma, voff, and logN, respectively, are as the following:

LineFitting/nh3_testcubes.py

Line 78 in 17bd16a

scale = np.array([[0.2, 0.1, 0.5, 0.01]])

My biggest concern right now is the voff range. Without some sort of beam smoothing between the pixels, individual spectra in the cube can be 'velocity-incoherent' from one another if the voff gradient is larger enough. An instance of this issue can be seen in the example NH3 (1,1) line below, where the mean spectrum of the cube is shown in grey and the central spectrum is shown in red:

Test_NH3_11_example

Extra 5 K in the input Tkin?

I noticed there's a +5 term at the end of the following line that was retained from the earliest versions of this code. The term seems misplaced as it currently adds 5 K to the T_kin initially specified in the input.

LineFitting/nh3_testcubes.py

Line 131 in 6fa43e0

T = Temp[j] * (1 + gradX[j][0] * (xx - 1) + gradY[j][0] * (yy - 1)) + 5

@low-sky, do you recall what this term was intended for?

Keeping low velocity separation cases?

Are we going to remove the following lines or make them optional to preserve the low velocity-separation cases?

LineFitting/nh3_testcubes.py

Lines 60 to 66 in cd16972

# Find where centroids are too close
too_close = np.where(np.abs(Voff1-Voff2)<np.max(np.column_stack((Width1, Width2)), axis=1))
# Move the centroids farther apart by the length of largest line width
min_Voff = np.min(np.column_stack((Voff2[too_close],Voff1[too_close])), axis=1)
max_Voff = np.max(np.column_stack((Voff2[too_close],Voff1[too_close])), axis=1)
Voff1[too_close]=min_Voff-np.max(np.column_stack((Width1[too_close], Width2[too_close])), axis=1)/2.
Voff2[too_close]=max_Voff+np.max(np.column_stack((Width1[too_close], Width2[too_close])), axis=1)/2.

Faulty noise generation

The following lines add noise redundantly over where synthetic spectra have already been made:

LineFitting/nh3_testcubes.py

Lines 148 to 149 in 0f136c8

cube11 += np.random.randn(*cube11.shape) * noise_rms
cube22 += np.random.randn(*cube22.shape) * noise_rms

Suggestion: place these lines either outside the loop or have them modified to operate only on the current pixel.

Inverted Spectral Axis

Our SpectroscopicAxis objects are currently generated in the order of ascending velocity,

LineFitting/nh3_testcubes.py

Line 106 in 6355ae9

channelwidth = (5.72 * u.kHz / (nh3con.freq_dict[linename] * u.Hz)) * constants.c

which is the opposite of what we're writing in the header, i.e., in the order of ascending frequency / descending velocity:

LineFitting/nh3_testcubes.py

Line 185 in 6355ae9

'CDELT3': 5720.0,

To keep the synthetic cube headers consistent with those of the GAS data headers, I suggest introducing a negative sign to line 106 referenced above.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.