wmwv / cosmo Goto Github PK

1. Test de Sitter (Om, Ol = 0, 1) cosmologies.
2. Consider adding a class to implement.
3. See if anything currently breaks for this special case.

1. Define a Cosmology interface.
2. Implement FlatLCDM struct in Cosmology interface.
3. Implement LambdaCDM struct in Cosmology interface.

Make HubbleTime and TElliptic not exported.
Make w0 exported from the Cosmology struct.

Add performance benchmarks

1. Luminosity distance calculations and inverse E(z) function.
2. Measure performance
3. Determine if there are performance gains of more directly rewriting inverse E(z)
4. Measure if the stacking of function calls creates performance slowdown
5. Determine if E(z) should use an if or switch statement to avoid the math.Sinh calculation for Omega_curvature = 0.
6. Implement any performance gains above.

1. Write out clear examples to highlight usage.
2. Separate from tests for specific behavior.

1. Run test coverage.
2. List uncovered functions.
3. Add tests for uncovered exported functions

Current types don't actually do anything with Tcmb0.

1. Remove this attributes from the types FlatLCDM, LambdaCDM, WCDM, and WACDM.
2. Remove the zero-setting struct initializations from the tests and examples.

Using elliptic integrals to speed of comoving distance calculation.

1. Legendre form
2. Carlson form.

Add AngularDiameterDistance function

There is some code in to vectorize Evec calculations, but there's not a clear use model informing the design. The Evec function is not otherwise used internally.

Remove Evec functions and associated tests.

Add special case analytic comoving distance for Omega_M-only (Omega_Lambda)=0.

Make a fmt.Println(cos) format nicely. E.g.,

{H0: 70, Om0: 0.27, Ol0: 0.73, W0: -0.9, WA: 3}

Clean up godoc.org presentation. Mostly line breaks.

Remove LookbackTimeIntegrate from FLRW interface

This is an implementation choice that doesn't need to be exposed in the public interface.

The WCDM.ComovingDistance is currently wrong for Nonflat LCDM cases.

1. Add test for WCDMComovingDistanceNonflatLCDM
2. Fix wcdm.go
3. Check lambdacdm.go, wacdm.go as well.

1. Make functions such as ComovingTransverseZ1Z2Integrate, AgeOM, [...] private.
2. Centralize some more functions in util.go or otherwise reduce duplication.

Want to be able to interrogate FLRW types about their flatness in a generic way.

Could imagine having a generic Getter framework, but let's restrict this issue to just Ok0().

[No Setters in any case as the cosmology structs should be immutable.]

Make the quad.Fixed-calling functions:

func (cos *Cosmology) ComovingDistanceZ1Z2Integrate(z1, z2 float64) (distance float64)
func (cos *Cosmology) LookbackTimeIntegrate(z float64) (time float64)
func (cos *Cosmology) AgeIntegrate(z float64) (time float64)

accept an argument specifying the number of integration points.

This isn't particularly likely to be used, and it would be better to instead specify relative or absolute tolerance, but having n hardcoded is worse.

Check and correct test cases for wcdm_test, wacdm_test

1. Several of the tests appear to have been calculated with w0=-1 instead of w0=-1.2. Use astropy.cosmology.wCDM, w0waCDM to correct the expected values.
2. Check wcdm_test.go
3. Check wacdm_test.go
4. Correct the errors in the implementation that lead to those tests currently passing.

1. Describe types as supporting all of their methods rather than just being structs.
2. Make sure top-level cosmo summarize the cosmologies supported.

All cosmologies need H0, then Om0, then Ol0, then W0, then WA.

Reorder struct attributes to put H0 to match this so that one can have

EdS(H0)
FlatLCDM(H0, Om0)
LambdaCDM(H0, Om0, Ol0)
WCDM(H0, Om0, Ol0, W0)
WACDM(H0, Om0, Ol0, W0, WA)

Note that EdS doesn't current exist as a type listing it here captures the point of why there's a certain natural order to the arguments.

1. Include the cosmological parameters in the table-drive tests.
2. Use these to create truly table-driven tests. Where the map is iterated over instead of having specific functions for each test.

E.g., the current test says this:

var answersWCDM = map[string][]float64{
	//   wCDM(70, 0.3, 0.7, -1.2).distmod(z)
	"WCDMDistanceModulus":           []float64{42.32710911, 44.17957201, 46.03118144, 47.09228735},
	//   wCDM(70, 0.3, 0.7, -1.1).luminosity_distance(z)
	"WCDMLuminosityDistanceFlat": []float64{2877.10314183, 6734.38177991, 15823.59621899, 25841.56448508},
}

Change to something more like

var answersWCDM = []struct {
    H0 float64
    Om0 float64
    Ol0 float64
    W0 float64
    name string
    out float64
}{
	//   wCDM(70, 0.3, 0.7, -1.2).distmod(z)
	{70, 0.3, 0.7, -1.2, "WCDMDistanceModulus", []float64{42.32710911, 44.17957201, 46.03118144, 47.09228735}},
	//   wCDM(70, 0.3, 0.7, -1.1).luminosity_distance(z)
	{70, 0.3, 0.7, -1.1, "WCDMLuminosityDistanceFlat", []float64{2877.10314183, 6734.38177991, 15823.59621899, 25841.56448508},
}

1. Wrap tests in test runner functions to create a clearer table-driven approach.
2. Expand number of cosmological parameter regimes tested using new table-driven format.

Add benchmarks for wcdm, wacdm

Define structs and methods for

1. w0CDM
2. waCDM

Rename Cosmology interface to FLRW. That's more specifically the interface that the methods have to fine. And the name of the package cosmo already captures that part of the name.

1. Improve the documentation for each function
2. Provide references for algorithms/approaches used.

1. Compare performance to AstroPy cosmology
2. Explore alternate ways of doing vectorization in both AstroPy and Go

I think that LambdaCDM doesn't correctly calculate luminosity distance in non-flat cosmologies.

1. Write luminosity distance test for non-flat LambdaCDM
2. Correct code behavior to pass test

See if it's worth casting, e.g., a flat WCDM into FlatLCDM to reduce the redundancy between function calculations.

1. Is it possible?
2. Is it efficient?
3. Does it reduce code complexity?

Satisfy the Go linter, golang/lint/golint