ucl-exoplanets / wayne Goto Github PK

SAMP-SEQ= SPARS5
Image Size
Sample
Number Full Frame 512x512 256x256
1 2.932 0.853 0.280
2 7.933 3.775 2.629
3 12.934 6.696 4.978
4 17.935 9.618 7.327
5 22.935 12.539 9.676
6 27.936 15.461 12.025
7 32.937 18.382 14.374
8 37.938 21.304 16.723
9 42.938 24.225 19.072
10 47.939 27.147 21.421
11 52.940 30.068 23,770
12 57.941 32.990 26.119
13 62.942 35.911 28.468
14 67.942 38.833 30.817
15 72.943 41.754 33.166

The seed still seems to be set correctly (i.e random) but the value is always reported as 0

... to something more specific that doesnt match an existing project

Currently the last subsample in a sample up the ramp can be very short, as it fills the time between the current point and the cutoff. In order for the approximations to work it should spill over to the next read or the whole method re-evaluated.

Like some real observations we want to be able to make alternate exposures scan up and down.

The seed is defined in the c code. Instead it should be passed in from python to ensure fixed seed builds will be the same.

Even if we fix this using different numbers of cores will give different results. I think thats ok for now as long as its clear and the same seed/core combo gives the same result

Numpy is needed to compile the c extensions but the current definition means you cant install the package without first installing numpy, despite installing the requirements being one of the first steps.

See here for a solution

We should add instructions to the readme on how to fix this. We should also address the warning.

python setup.py develop
Warning: Extension name 'pyparallel' does not match fully qualified name 'wayne.pyparallel' of 'pyparallel.pyx'
running build_ext
building 'pyparallel' extension
gcc -fno-strict-aliasing -I/Users/ryan/anaconda/envs/wayne/include -arch x86_64 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/ryan/anaconda/envs/wayne/lib/python2.7/site-packages/numpy/core/include -I/Users/ryan/anaconda/envs/wayne/include/python2.7 -c pyparallel.c -o build/temp.macosx-10.9-x86_64-2.7/pyparallel.o -fopenmp -lm -O3
clang: warning: -lm: 'linker' input unused [-Wunused-command-line-argument]
clang: error: unsupported option '-fopenmp'
error: command 'gcc' failed with exit status 1

Current generation times are long and only use a single core. Parallelise this process.

Current status

Results (14.11s):
      38 passed
      15 failed

I.e make dead / hot / unstable pixels replicate real behavior

There are lots of try: excepts that could be replaced by gets.

Our current set our requirements are old and are in conflict (i.e. the numpy and scipy versions).

After we have reliable tests (particularly end-to-end), upgrade the packages to the latest set of stable versions.

Currently the visit planner when automatically generating read times does not consider the time taken to move the spacecraft.

Traceback (most recent call last):3 done (samp 437/447)
  File "run_visit.py", line 179, in <module>
    obs.run_observation()
  File "/Users/ryan/PythonPackages/WFC3Sim/observation.py", line 344, in run_observation
    self._generate_exposure(start_time, filenum)
  File "/Users/ryan/PythonPackages/WFC3Sim/observation.py", line 406, in _generate_exposure
    progress_bar=self.progess,
  File "/Users/ryan/PythonPackages/WFC3Sim/exposure_generator.py", line 316, in scanning_frame
    scale_factor, add_flat)
  File "/Users/ryan/PythonPackages/WFC3Sim/exposure_generator.py", line 642, in _gen_subsample
    wl_psf_std, pixel_array)
  File "/Users/ryan/PythonPackages/WFC3Sim/exposure_generator.py", line 750, in _psf_distribution
    yx = np.insert(yx, len(yx), np.zeros(yx_size - len(yx)))
ValueError: negative dimensions are not allowed

only happens sometimes, but repeatably to the same part and seems to depend on seed.

so we can create a stable virtual env

I cant replicate this, if you have the issue let me know here.

There probably a lot of dead code hanging around, lets clean it out.

The gaussian model converts flux to amplitude on initialisation and therefore if the stddev is changed after amplitude is preserved not flux. This may or may not be the desired outcome, but it should be known.

Perhaps a warning should be raised? amplitude could also be calculated from flux on the fly.

Currently there is a hack that rewrites the c code and calls a compile during program execution in wayne/pyparallel_compiling.py. The code should be compiled using setup.py and the number of cores be accepted as a parameter at runtime.