Coder Social home page Coder Social logo

juanep97 / iop4 Goto Github PK

View Code? Open in Web Editor NEW
5.0 3.0 1.0 724 KB

IOP4, the Interactive Optical Photo-Polarimetric Python Pipeline.

Home Page: https://juanep97.github.io/iop4/

License: BSD 3-Clause "New" or "Revised" License

Makefile 0.10% Python 84.02% HTML 9.43% CSS 1.89% JavaScript 4.56%
astronomy astrophysics python3 photometry polarimetry

iop4's Introduction

IOP4 is a complete rewrite of IOP3, a pipeline to work with photometry and polarimetry of optical data from CAHA and OSN observatories. It is built to ease debugging and inspection of data.

IOP4 implements Object Relational Mapping (ORM) to seamlessly integrate all information about the reduction and results in a database which can be used to query and plot results, flag data and inspect the reduction process in an integrated fashion with the whole pipeline. It also ships with an already built-in web interface which can be used out of the box to browse the database and supervise all pipeline processes.

See details in Juan Escudero Pedrosa et al 2024 AJ 168 84.

Installation

We recommend installing IOP4 in an isolated environment as described below. IOP4 is hosted in PyPI software repository.

Option 1: Using a virtual environment

Note: IOP4 requires Python 3.10 or later. You can check your Python version with python --version. If you have a compatible version, you can skip this step.

If you don't have Python 3.10 or later, you can install pyenv and pyenv-virtualenv, which will manage python versions for you. You can use the automatic installer pyenv-installer:

    $ curl https://pyenv.run | bash

Follow the instructions that this command outputs to add pyenv to PATH (or copy the commands from https://github.com/pyenv/pyenv for your shell). Restart your terminal, or source the file (e.g. . ~/.bashrc or . ~/.zshrc) Then, run

    $ pyenv install 3.10
    $ pyenv virtualenv 3.10 iop4-venv
    $ pyenv activate iop4-venv

Now you will have a virtual environment with the right Python version, and you can continue with the next step. To deactivate, just run pyenv deactivate.

With the environment activated, you can install IOP4 latest version by running:

    $ pip install iop4

Alternatively, you can clone this repository and install IOP4:

    $ git clone '[email protected]:juanep97/iop4.git'
    $ cd iop4
    $ pip install .

or pip install -e . if you want to install it in developer mode.

Option 2: Using conda/mamba

As the previous option, create and activate the environment as follows:

    $ conda create -n iop4 python=3.10
    $ conda activate iop4

Then run:

    $ pip install iop4

Alternatively, you can also clone this repository and run (inside the root directory of the cloned repository):

    $ pip install .

or pip install -e . if you want to install it in developer mode.

If you followed the steps in any of the two options above, you will have installed the module iop4lib and the iop4 command, and the iop4site project.

Configuration

After installation, take a look at the example configuration file (iop4lib/config.example.yaml), set the appropriate variables (path to the database, data directory, astrometry index files path, credentials, etc) and save it to ~/.iop4.config.yaml.

Running Tests

To run the tests, first follow the previous steps to install IOP4 in developer mode and configure it. The test dataset will be automatically downloaded to your home directory

    $ pytest -vxs tests/

If it is the first time executing IOP4, the astrometry index files will be downloaded to astrometry_cache_path (see config.example.yaml). This will take some time and a few tens of GB, depending on the exact version.

Warning: in some macOS systems, the process might hang up. Execute export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES or add that line to your shell init script.

Usage

If no previous database exists, make sure to create it. You can do it automatically from the iop4site/ directory by using

    $ python manage.py makemigrations
    $ python manage.py migrate

Then, create a user with

    $ python manage.py createsuperuser

You can later use these credentials to login to the admin site, where you will need to add any sources of interest to the empty catalog.

To manually back up all data from the DB, you can use

    $ python manage.py dumpdata --natural-primary --natural-foreign --format=yaml > priv.dumps.yaml

This file can be used to reload the data to the DB with:

    $ python manage.py loaddata priv.dumps.yaml

An utility script, iop4site/resetdb.py, is provided which will completely reset the DB keeping catalog and user's data.

As A Program

The pipeline script iop4 can be invoked as

    $ iop4 --epoch-list tel1/yymmdd tel2/yymmdd

to download and reduce the epoch yymmdd from telescopes tel1 and tel2 respectively. For example: iop4 -l T090/230430.

To serve the results in Django debug server, change to the iop4site directory and run

    $ python manage.py runserver

although this server is only recommended for debugging purposes, and you should use another server in production (see Django documentation).

As A Library

iop4lib uses django ORM and it needs to be configured before using it. Therefore, you should do

    import iop4lib
    iop4lib.Config(config_db=True)

once at the start of your script. IOP4 configuration can be accessed anywhere without configuring the ORM doing import iop4lib; iop4conf = iop4lib.Config(config_db=False).

This way of configuring IOP4 should be also valid inside IPython Shell, but not for Jupyter notebooks, since their asynchronous output interferes with Django ORM. To use IOP4 inside a notebook, see below. More details can be found in the documentation for iop4lib.Config.

Now you are ready to import and use IOP4 models from your Python script, e.g:

    import iop4lib
    iop4lib.Config(config_db=True)
    from iop4lib.db import RawFit, ReducedFit, Epoch, PhotoPolResult

    # this will print the number of T220 nights reduced:
    print(Epoch.objects.filter(telescope="CAHA-T220").count()) 

    # this will reduce the last T220 night:
    Epoch.objects.filter(telescope="CAHA-T220").last().reduce()

In Interactive Notebooks (JupyterLab)

You can use IOP4 in an interactive manner inside a Jupyter notebook. The following lines also activate matplotlib's graphical output (deactivated by default, as some plots may be generated inside the server).

%autoawait off
%load_ext autoreload
%autoreload all

import iop4lib.config
iop4conf = iop4lib.Config(config_db=True, gonogui=False, jupytermode=True)   

Tips

You can get an IPython interactive terminal after running iop4 using the -i option. You can override any config option using the -o option, or by setting environment variables, e.g.

    $ IOP4_NTHREADS=20 iop4 -i -o log_file=test.log --epoch-list T090/230313 T090/230317

Check iop4 --help for more info.

Documentation

To build and show the documentation, run

    $ make docs-sphinx
    $ make docs-show

The documentation for the latest release is hosted in this repository's GitHub Pages.

Contribute

You are welcome to contribute to IOP4. Fork and create a PR!

Citing IOP4

If you use IOP4, or any result derived from it, we kindly ask you to cite the following references:

DOI AJ

DOI Zenodo

You can use the following BibTeX entries:

@article{iop4_AJ,
  doi = {10.3847/1538-3881/ad5a80},
  url = {https://dx.doi.org/10.3847/1538-3881/ad5a80},
  year = {2024},
  month = {jul},
  publisher = {The American Astronomical Society},
  volume = {168},
  number = {2},
  pages = {84},
  author = {{Escudero Pedrosa}, Juan and {Agudo}, Ivan and {Morcuende}, Daniel and {Otero-Santos}, Jorge and {Bonnoli}, Giacomo and {Piirola}, Vilppu and {Husillos}, C{\'e}sar and {Bernardos}, Mabel and {L{\'o}pez-Coto}, Rub{\'e}n and {Sota}, Alfredo and {Casanova}, V{\'\i}ctor and {Aceituno}, Francisco and {Santos-Sanz}, Pablo},
  title = {IOP4, the Interactive Optical Photo-Polarimetric Python Pipeline},
  journal = {The Astronomical Journal},
}

@software{iop4_zenodo,
  author       = {{Escudero Pedrosa}, Juan and
                  {Morcuende Parrilla}, Daniel and
                  Otero-Santos, Jorge},
  title        = {IOP4},
  year         = 2024,
  publisher    = {Zenodo},
  doi          = {10.5281/zenodo.10222722},
  url          = {https://zenodo.org/doi/10.5281/zenodo.10222722}
}

iop4's People

Contributors

joteros avatar juanep97 avatar morcuended avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

rlopezcoto

iop4's Issues

change README

iop4/README.md

Line 41 in ee4ce30

$ iop4 -l tel1/yymmdd tel2/yymmdd

should be iop4.py instead of iop4, but I would suggest to change the bin name to that without extension everywhere

Zenodo upload

For uploading it to zenodo, you also have to do it @juanep97, linking the repository to your zenodo page.

Implement histogram equalization for astronometric calibration

Implement histogram equalization during astrometric calibration, it might lead to a general speed up of the process; specially for images with sources of very different brightness (such us those containing bright stars). Those kind of images currently take a longer time to calibrate, or even fail; histogram equalization might allow their calibration. Some tests will be needed to decide whether it should be the default.

https://scikit-image.org/docs/stable/auto_examples/color_exposure/plot_equalize.html

Document CAFOS equations and substitute them with clearer expressions.

These lines taken from IOP3 code are not very clear.

            Theta_0 = 0
        
            if Q_I >= 0:
                Theta_0 = math.pi 
                if U_I > 0:
                    Theta_0 = -1 * math.pi
                # if Q_I < 0:
                #     Theta_0 = math.pi / 2
                
            Theta = 0.5 * math.degrees(math.atan(U_I / Q_I) + Theta_0)
            dTheta = 0.5 * 180.0 / math.pi * (1 / (1 + (U_I/Q_I) ** 2)) * math.sqrt( (dU_I/Q_I)**2 + (U_I*dQ_I/Q_I**2)**2 )

I think they can be just substituted by the same expressions that DIPOL class uses.

Further instructions on how to setup iop4

Still not clear to me how to set the configuration file (path to real DB, astrometry cache, etc).

I guess related it's related to knowing if these two scripts actually work

    $ python manage.py makemigrations
    $ python manage.py migrate

The first one returns No changes detected

The second one seems to run fine (Running migration messages and so on)

Then, the command python manage.py dumpdata --natural-primary --natural-foreign --format=yaml > priv.dumps.yaml returns:

CommandError: Unable to serialize database: no such table: iop4api_astrosource

Also the test test_build_reduced_multiproc takes too long, I guess because it's trying to download astrometry files.

Implement an alert system

Since we have historical blazar monitoring data, might be a good idea to have some kind of alert trigger for sources showing exceptional brightness with respect to their usual flux. It could be used as a ToO alert system.

Warnings in CI tests from setuptools_scm

This warning is repeated in the github CI Actions many times during tests

 /opt/hostedtoolcache/Python/3.11.6/x64/lib/python3.11/site-packages/setuptools_scm/git.py:163: UserWarning: "/home/runner/work/iop4/iop4" is shallow and may cause errors
  warnings.warn(f'"{wd.path}" is shallow and may cause errors')
/opt/hostedtoolcache/Python/3.11.6/x64/lib/python3.11/site-packages/setuptools_scm/git.py:163: UserWarning: "/home/runner/work/iop4/iop4" is shallow and may cause errors
  warnings.warn(f'"{wd.path}" is shallow and may cause errors')
/opt/hostedtoolcache/Python/3.11.6/x64/lib/python3.11/site-packages/setuptools_scm/git.py:163: UserWarning: "/home/runner/work/iop4/iop4" is shallow and may cause errors
  warnings.warn(f'"{wd.path}" is shallow and may cause errors')

https://github.com/juanep97/iop4/actions/runs/7034575267/job/19142940434?pr=39

Should be ReducedFit.mdata a cached or lazy property?

Right now, RawFit.mdata, ReducedFit.mdata are properties that read and return the data from the files every time they are used. There could be two alternatives with different advantages and drawbacks:

  • Make them cached properties so that they read the file only one, saving quite a bit of disk read access. This would make some functions and views slightly faster.
  • Make RawFit.mdata a cached property that reads data only one. Make ReducedFit.mdata a cached property that computes the value on the fly, applying the master calibrations frames on the fly to the rawfit. This would make it the pipeline processes only slightly slower, however, for the iop4admin views using the data, such as the stats on the detailed views, it might add some seconds to the page load. Some tests are needed to check if these differences are significant (applying the calibration frames, once they are built, is quite fast).

The main advantage of this point is that disk space would be reduced by a factor of x5. Right now, since the reduced FITS are saved using float64 to keep precision (#30 ), they take x4 times the size of the raw images (uint16 usually). This method would completely eliminate these files from the disk. the .build_file would only build and save the WCS header to disk (a few kilobytes at most), and the .header would read this.

New release?

I think it is time to make the first IOP4 release to have a tagged version to compare later on, for bookkeeping, provenance, etc. Could be 0.1.0

Versions of requirements are too tightly fixed

iop4/pyproject.toml

Lines 20 to 40 in 090cc97

"numpy==1.24.2",
"matplotlib==3.7.1",
"bokeh==3.2.2",
"scipy==1.10.1",
"astropy==5.2.2",
"astroquery",
"photutils==1.8.0",
"pandas",
"scikit-learn==1.2.2",
"scikit-image",
"coloredlogs",
"ipython",
"django==4.1.7",
"astrometry==4.1.2",
"multiprocess==0.70.14",
"pypandoc",
"termcolor",
"pyyaml<5.4",
"psutil",
]

In principle, there is no showstopper to run iop4 with the latest Python version 3.12 (3.13 coming already in a few months) other than some requirements above that need to be updated as well to make installation possible. I ran iop4 tests with Python 3.12 leaving dependency versions free (e.g. setting "matplotlib>=3.7.1" instead of "matplotlib==3.7.1"), and it worked.

Still to be thoroughly checked though. But something to keep in mind.

Use only source calibrators for the zero point

When computing the zero point to be used in the relative photometry of a given source, all calibrators in the field are used, not only those that are calibrators to the source:

calib_mag_zp_array = np.array([result.mag_zp or np.nan for result in photopolresult_L if result.astrosource.srctype == SRCTYPES.CALIBRATOR]) # else it fills with None also and the dtype becomes object

        # 3. Average the zero points

        calib_mag_zp_array = np.array([result.mag_zp or np.nan for result in photopolresult_L if result.astrosource.srctype == SRCTYPES.CALIBRATOR]) # else it fills with None also and the dtype becomes object
        calib_mag_zp_array = calib_mag_zp_array[~np.isnan(calib_mag_zp_array)]

        calib_mag_zp_array_err = np.array([result.mag_zp_err or np.nan for result in photopolresult_L if result.astrosource.srctype == SRCTYPES.CALIBRATOR])
        calib_mag_zp_array_err = calib_mag_zp_array_err[~np.isnan(calib_mag_zp_array_err)]

Enable automatic code checks?

Do we want to enable automatic checks for format, syntax and linting?
It would require to make a lot of modifications and cleanup of the code

Docs not correctly deployed to github pages

E.g, this is the github pages after deployment (docs.yml) of last version (v1.1.0).
imagen
Example notebooks are also not generating the images.

This is local result of make docs-sphinx:
imagen

So:

  1. The version is not correctly shown
  2. The examples are not working.

ReducedFit files large size

Reduced Fit sizes appear to be much bigger (x4?) than the corresponding rawfit.

Let's investigate why, and how to avoid this.

Add instructions on how to run the tests

Installed iop4 in edit mode, downloaded the tests tarball iop4testdata.tar.gz and placed it in my home directory. Then run pytest. It tries to use the config file .../iop4/config/config.yaml. Shouldn't it use instead Path('~/.iop4tests/').expanduser() / "config.tests.yaml"

Estimation of radii for photometry aperture

From #67

We should find a way of systematically setting the values of the radii of the annulus used for photometry aperture:

During these days I saw that for some specific sources and nights, it was behaving better. In particular for CAFOS2.2 2023-12-20 1101+384, using 3.0r made the two points inconsistent with OSN observations, and made the photometry uncertainty very large. Using 6.0r made the uncertainties sensible AND compatible with the other instruments. It also didn't affect significantly other results, as you can see, it only increases slightly the discrepancy with the test reference... but that reference comes from IOP3 and is not written in stone... so until we replace it with something more solid, we can allow a bit more of discrepancy, I think.

Anyway, we should open an issue so we don't forget to look into this. These values have changed already several times in an erratic way. We should investigate it systematically. At some point, we will definitely need to implement a way to handle several cases as in #66 for the astrometry calibration parameters.

Bulk reducing with multiprocessing gives locked database error

Since we are using SQLite and it has some trouble with high concurrency, using multiprocessing sometimes gives "Database is locked" errors.

In production, we could think of moving to a different database backend such as postgre. But tests should use SQLite, and this error makes the bulk reduce with multiprocessing test fail.

Post installation steps

Add post-installation steps:

  • Install js9
  • Basic configuration of paths in config.yml

Explore if these steps can be done in pyproject.toml (related to #15) or have to be done in setup.py/.cfg instead.

Remove SRCTYPES.CALIBRATOR

SRCTYPES should correspond to physical source types. Whether an object is a calibrator should be defined automatically using its calibrates field. This can be implemented with a custom model manager that annotates the objects with a is_calibrator field.

Allow several alternative names for astrosources.

Sometimes there have been errors or different conventions in source names.
We should rename other_name to other_names and allow it to be a comma separated list of names.
It will allow IOP4 to work with the different conventions used along the history of -several- programs within one catalog.

E.g. 2145+067 a.k.a B 2145+067 was wrongly named B2135 in the catalog, but was observed with that name during some time due to an error in the observers spreadsheet. We could include the wrong name in the catalog (and a indication that the name is only because of an error, to reduce the files with that name).

Organization to contain software packages?

Hi, since this software is meant to be published in a refereed publication and so on, it always looks better if it is contained in a "permanent" organization instead of a personal github repo.
I suggest that we can create the "vhega" organization and migrate libraries like this one (maybe also MUTIS) The migration should be transparent for owners/admins and so on, but it will just be contained under a different URL that will make it look more permanent.

Next release should indicate migration step

PR #77 renamed AstroSource.other_name to AstroSource.other_names. For this to be correctly taken into during the migration step of the update, it must be manually indicated by editing the migration file and altering it to:

    operations = [
        migrations.RenameField(
            model_name='astrosource',
            old_name='other_name',
            new_name='other_names',
        ),
        ...

These instructions should appear in the release notes.

Investigate negative flux errors

Sometimes a negative flux is saved in the database as aperphot result. This gives an error downstream as in:

2023-10-10 20:42:11 - iop4lib.telescopes.cahat220 [cahat220.py:343] - DEBUG - Computing relative polarimetry for <AstroSource S4 0954+65 4>.                                                                2023-10-10 20:42:11 - iop4lib.telescopes.cahat220 [cahat220.py:417] - WARNING - polarimetry_group=[ReducedFit.objects.get(id=52269), ReducedFit.objects.get(id=52272), ReducedFit.objects.get(id=52271), ReducedFit.objects.get(id=52270)]: negative flux mean encountered while relative polarimetry for astrosource=AstroSource.objects.get(name='S4 0954+65 4') ??!! It will be nan, but maybe we should look into th
is...                                                                                                                                                                                                       
Traceback (most recent call last):                                                                                                                                                                          
  File "/home/vhega/miniconda3/envs/iop4/bin/iop4", line 8, in <module>                                                                                                                                     
    sys.exit(main())                                                                                                                                                                                        
  File "/home/vhega/iop4/iop4lib/iop4.py", line 195, in main                                                                                                                                                
    process_epochs(epochs_to_process, args.force_rebuild, check_remote_list=~args.skip_remote_file_list)                                                                                                    
  File "/home/vhega/iop4/iop4lib/iop4.py", line 65, in process_epochs                                                                                                                                       
    epoch.compute_relative_polarimetry()                                                                                                                                                                    
  File "/home/vhega/iop4/iop4lib/db/epoch.py", line 674, in compute_relative_polarimetry                                                                                                                    
    return list(map(f, clusters_L))                                                                                                                                                                         
  File "/home/vhega/iop4/iop4lib/db/epoch.py", line 672, in <lambda>                                                                                                                                        
    f = lambda x: Telescope.by_name(self.telescope).compute_relative_polarimetry(x, *args, **kwargs)                                                                                                        
  File "/home/vhega/iop4/iop4lib/telescopes/cahat220.py", line 419, in compute_relative_polarimetry                                                                                                         
    mag_inst = -2.5 * math.log10(flux_mean)                                                                                                                                                                 
ValueError: math domain error                                                                                                                                                                               
(iop4) vhega@quasar:~$     

Also, this error is not catched anywhere and breaks the pipeline execution.

Ocurrences (IOP4 version main @ d9d65f2).

  • During relative photo-polarimetry reduction for source "S4 0954+65 4" in CAHA-T220/2023-10-09/caf-20231010-03:36:55-sci-agui.fit.

Add a working config file

The config file given as an example does not work out of the box. It would be great that iop4 help and basic functionality would work out of the box after setup installation

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.